Re: [HACKERS] [BUGS] BUG #4660: float functions return -0
Tom Lane wrote: ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp writes: We already have some codes to avoid -0 float8um (unary minus), but there are no protection in trunc(), ceil() and round() at least. I looked into the CVS history to find out when the anti-minus-zero code got put into float8um. It seems to have been done by Tom Lockhart here: http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/float.c.diff?r1=1.13;r2=1.14 The CVS commit message says Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). along with some other unrelated changes. I can find no evidence in the mailing list archives that there was any discussion about the point, so I think Tom did that on his own authority. I'm of the opinion that minus zero was put into the IEEE floating point standard by people who know a great deal more about the topic than anyone on this list does, and that we do not have the expertise to be second-guessing how it should work. Not long ago we took out code that was interfering with spec-compliant treatment of IEEE infinity; I think we should take out this code too. Yes, it will be platform dependent, because various platforms get the IEEE spec wrong to some degree, but so what? This is hardly the only platform dependence of that kind. Agreed. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #4660: float functions return -0
Tom Lane t...@sss.pgh.pa.us writes: The CVS commit message says Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). I'm of the opinion that minus zero was put into the IEEE floating point standard by people who know a great deal more about the topic than anyone on this list does, and that we do not have the expertise to be second-guessing how it should work. Not long ago we took out code that was interfering with spec-compliant treatment of IEEE infinity; I think we should take out this code too. If the original complaint was that it looked ugly in query results then the right way to fix it would surely in float4out and float8out. Interfering with IEEE floating points may be a bad idea but surely it's up to us how we want to represent those values in text. But without a convenient and widely used binary format that kind of restricts our options. If we squash -0 on float[48]out then dumps will lose information. So I guess there's nothing we can do about it now. I wonder if we're going to find users complaining about things like displaying -0 matching results though... -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #4660: float functions return -0
Gregory Stark st...@enterprisedb.com writes: Tom Lane t...@sss.pgh.pa.us writes: I'm of the opinion that minus zero was put into the IEEE floating point standard by people who know a great deal more about the topic than anyone on this list does, and that we do not have the expertise to be second-guessing how it should work. Not long ago we took out code that was interfering with spec-compliant treatment of IEEE infinity; I think we should take out this code too. If the original complaint was that it looked ugly in query results then the right way to fix it would surely in float4out and float8out. Interfering with IEEE floating points may be a bad idea but surely it's up to us how we want to represent those values in text. But without a convenient and widely used binary format that kind of restricts our options. If we squash -0 on float[48]out then dumps will lose information. The point I'm trying to make is that we should deliver IEEE-compliant results if we are on a platform that complies with the spec. Right down to the minus sign. If that surprises people who are unfamiliar with the spec, well, there are a lot of things about floating point arithmetic that surprise people who aren't familiar with it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #4660: float functions return -0
On Wed, Feb 18, 2009 at 2:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: The point I'm trying to make is that we should deliver IEEE-compliant results if we are on a platform that complies with the spec. Right down to the minus sign. If that surprises people who are unfamiliar with the spec, well, there are a lot of things about floating point arithmetic that surprise people who aren't familiar with it. Agreed. There are plenty of things about floats that are downright wonky, and when people start seeing minus zero in their float computations it might prompt them into doing some reading, and figuring out that what they really wanted was numeric. (not saying that floats are without application, but I've often encountered them in places they ought not to be) Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #4660: float functions return -0
Brendan Jurd dire...@gmail.com writes: On Wed, Feb 18, 2009 at 2:57 AM, Tom Lane t...@sss.pgh.pa.us wrote: The point I'm trying to make is that we should deliver IEEE-compliant results if we are on a platform that complies with the spec. Right down to the minus sign. If that surprises people who are unfamiliar with the spec, well, there are a lot of things about floating point arithmetic that surprise people who aren't familiar with it. Agreed. There are plenty of things about floats that are downright wonky, and when people start seeing minus zero in their float computations it might prompt them into doing some reading, and figuring out that what they really wanted was numeric. I pulled the special code out of float8um/float4um and got the following two changes in the regression tests: *** src/test/regress/expected/numerology.outMon Aug 4 22:43:18 2008 --- src/test/regress/results/numerology.out Tue Feb 17 20:05:01 2009 *** *** 92,98 ORDER BY two, max_float, min_float; two | max_float | min_float -+--+--- !1 | 1.2345678901234e+200 | 0 2 |0 | -1.2345678901234e+200 (2 rows) --- 92,98 ORDER BY two, max_float, min_float; two | max_float | min_float -+--+--- !1 | 1.2345678901234e+200 |-0 2 |0 | -1.2345678901234e+200 (2 rows) *** *** 104,110 ORDER BY two, max_float, min_float; two | max_float | min_float -+--+--- !1 | 1.2345678901234e+200 | 0 2 |0 | -1.2345678901234e+200 (2 rows) --- 104,110 ORDER BY two, max_float, min_float; two | max_float | min_float -+--+--- !1 | 1.2345678901234e+200 |-0 2 |0 | -1.2345678901234e+200 (2 rows) == This is on a minus-zero-clean platform of course (same results on Fedora 9 and current Mac OS X). My HP box still produces the old results, so we will need two variants of this expected-result file. Other platforms might show yet other diffs of course, but we'll have to wait for buildfarm results to know more. Last call for objections ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #4660: float functions return -0
I reported the following bug to -bugs, and I'd like to discuss whether we need to fix the issue or how to fix it. ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp wrote: Bug reference: 4660 PostgreSQL version: 8.3.3 Operating system: Fedora 8 Description:float functions return -0 Details: Float8 versions of trunc(), ceil() and round() could return -0 on some version of glibc. postgres=# SELECT pg_catalog.trunc((-0.1)::float8); -0 postgres=# SELECT pg_catalog.ceil((-0.1)::float8); -0 postgres=# SELECT pg_catalog.round((-0.1)::float8); -0 We already have some codes to avoid -0 float8um (unary minus), but there are no protection in trunc(), ceil() and round() at least. It is platform-dependent behavior (msvcrt doesn't return -0), and there is a difference between float8 and numeric (numeric doesn't support -0). 1. Remove 'avoid -0' from float8um because -0 is a possible value for floating point numbers. 2. Add 'avoid -0' codes to those functions. (Are there any places where we also add it?) 3. Move 'avoid -0' codes to float8out() and float8send(). '-0' could be stored in database, but users receives only '+0'. Fixes might be needed by float4 versions. I'll write a patch when we come to a decision. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #4660: float functions return -0
ITAGAKI Takahiro itagaki.takah...@oss.ntt.co.jp writes: We already have some codes to avoid -0 float8um (unary minus), but there are no protection in trunc(), ceil() and round() at least. I looked into the CVS history to find out when the anti-minus-zero code got put into float8um. It seems to have been done by Tom Lockhart here: http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/float.c.diff?r1=1.13;r2=1.14 The CVS commit message says Check for zero in unary minus floating point code (IEEE allows an explicit negative zero which looks ugly in a query result!). along with some other unrelated changes. I can find no evidence in the mailing list archives that there was any discussion about the point, so I think Tom did that on his own authority. I'm of the opinion that minus zero was put into the IEEE floating point standard by people who know a great deal more about the topic than anyone on this list does, and that we do not have the expertise to be second-guessing how it should work. Not long ago we took out code that was interfering with spec-compliant treatment of IEEE infinity; I think we should take out this code too. Yes, it will be platform dependent, because various platforms get the IEEE spec wrong to some degree, but so what? This is hardly the only platform dependence of that kind. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
