Re: [BUGS] BUG #4660: float functions return -0 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [BUGS] BUG #4660: float functions return -0
Date
Msg-id 27216.1234920885@sss.pgh.pa.us
Whole thread Raw
In response to Re: [BUGS] BUG #4660: float functions return -0  (Brendan Jurd <direvus@gmail.com>)
List pgsql-hackers
Brendan Jurd <direvus@gmail.com> writes:
> On Wed, Feb 18, 2009 at 2:57 AM, Tom Lane <tgl@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.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


pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: SE-PostgreSQL and row level security
Next
From: decibel
Date:
Subject: Re: The science of optimization in practical terms?