From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brendan Jurd <direvus(at)gmail(dot)com> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [BUGS] BUG #4660: float functions return -0 |
Date: | 2009-02-18 01:34:45 |
Message-ID: | 27216.1234920885@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Brendan Jurd <direvus(at)gmail(dot)com> writes:
> On Wed, Feb 18, 2009 at 2:57 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.out Mon 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
From | Date | Subject | |
---|---|---|---|
Next Message | Md. Abdur Rahman | 2009-02-18 04:24:27 | building Postgresql in Windows XP |
Previous Message | Brendan Jurd | 2009-02-17 19:24:28 | Re: [BUGS] BUG #4660: float functions return -0 |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-02-18 05:23:37 | Re: The science of optimization in practical terms? |
Previous Message | KaiGai Kohei | 2009-02-18 00:31:19 | Re: SE-PostgreSQL and row level security |