| 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: | Whole Thread | Raw Message | 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 |