Re: [HACKERS] Floating point error - Mailing list pgsql-general

From Tom Lane
Subject Re: [HACKERS] Floating point error
Date
Msg-id 11694.1362507792@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Floating point error  (Maciek Sakrejda <m.sakrejda@gmail.com>)
Responses Re: [HACKERS] Floating point error  (Maciek Sakrejda <m.sakrejda@gmail.com>)
Re: [HACKERS] Floating point error  (Florian Weimer <fweimer@redhat.com>)
List pgsql-general
Maciek Sakrejda <m.sakrejda@gmail.com> writes:
> Thank you: I think this is what I was missing, and what wasn't clear
> from the proposed doc patch. But then how can pg_dump assume that it's
> always safe to set extra_float_digits = 3?

It's been proven (don't have a link handy, but the paper is at least
a dozen years old) that 3 extra digits are sufficient to accurately
reconstruct any IEEE single or double float value, given properly
written conversion functions in libc.  So that's where that number comes
from.  Now, if either end is not using IEEE floats, you may or may not
get equivalent results --- but it's pretty hard to make any guarantees
at all in such a case.

> Why the discrepancy between
> default behavior and what pg_dump gets?

Basically, the default behavior is tuned to the expectations of people
who think that what they put in is what they should get back, ie we
don't want the system doing this by default:

regression=# set extra_float_digits = 3;
SET
regression=# select 0.1::float4;
   float4
-------------
 0.100000001
(1 row)

regression=# select 0.1::float8;
       float8
---------------------
 0.10000000000000001
(1 row)

We would get a whole lot more bug reports, not fewer, if that were
the default behavior.

            regards, tom lane


pgsql-general by date:

Previous
From: James Cloos
Date:
Subject: Re: [HACKERS] Floating point error
Next
From: Tom Lane
Date:
Subject: Re: 9.2 timestamp function syntax error