Re: [HACKERS] Floating point error

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Floating point error
Дата
Msg-id 11694.1362507792@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Floating point error  (Maciek Sakrejda <m.sakrejda@gmail.com>)
Ответы Re: [HACKERS] Floating point error  (Maciek Sakrejda <m.sakrejda@gmail.com>)
Re: [HACKERS] Floating point error  (Florian Weimer <fweimer@redhat.com>)
Список 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 по дате отправления:

Предыдущее
От: James Cloos
Дата:
Сообщение: Re: [HACKERS] Floating point error
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 9.2 timestamp function syntax error