Re: [BUGS] BUG #4660: float functions return -0

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

In response to

Browse pgsql-bugs by date

  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

Browse pgsql-hackers by date

  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