Re: [HACKERS] Floating point error

Поиск
Список
Период
Сортировка
От Edson Richter
Тема Re: [HACKERS] Floating point error
Дата
Msg-id BLU0-SMTP44394984BEDFAC431AE534ACFFB0@phx.gbl
обсуждение исходный текст
Ответ на Re: [HACKERS] Floating point error  (Tom Duffey <tduffey@trillitech.com>)
Список pgsql-general
Em 05/03/2013 16:01, Tom Duffey escreveu:
> This conversation has moved beyond my ability to be useful but I want to remind everyone of my original issues in
caseit helps you improve the docs: 
>
> 1) Data shown in psql did not match data retrieved by JDBC. I had to debug pretty deep into the JDBC code to confirm
thata value I was staring at in psql was different in JDBC. Pretty weird, but I figured it had something to do with
floatingpoint malarky. 

As stated before, Java tries to be consistent across platforms. This is
different than a dozen of C and C++ implementations you will find (some
implementations will not be consistent even using same library on
different platforms).

>
> 2) The problem in #1 could not be reproduced when running on our test database. Again very weird, because as far as
psqlwas showing me the values in the two databases were identical. I used COPY to transfer some data from the
productiondatabase to the test database. 

Yes, this is really interesting. Is the production database running on
same platform (OS, architecture, updates) as the test database?

Regards,

Edson

>
> I now know that what you see in psql is not necessarily what you see in JDBC. I also know that you need to set
extra_float_digits= 3 before using COPY to transfer data from one database to another or risk differences in floating
pointvalues. Sounds like both pg_dump and the JDBC driver must be doing this or its equivalent on their own. 
>
> If the numeric types page of the documentation had mentioned the extra_float_digits then I might have been able to
solvemy own problem. I'd like you to add some mention of it even if it is just handwaving but will let you guys hash it
outfrom here. Either way, PostgreSQL rocks! 
>
> Tom
>
> On Mar 5, 2013, at 12:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> Maciek Sakrejda <m.sakrejda@gmail.com> writes:
>>> On Tue, Mar 5, 2013 at 10:23 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> 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.
>>> Isn't this a client rendering issue, rather than an on-the-wire encoding issue?
>> Nope, at least not unless you ask for binary output format (which
>> introduces a whole different set of portability gotchas, so it's
>> not the default either).
>>
>>             regards, tom lane
> --
> Tom Duffey
> tduffey@trillitech.com
> 414-751-0600 x102
>
>
>



В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Duffey
Дата:
Сообщение: Re: [HACKERS] Floating point error
Следующее
От: Ken Tanzer
Дата:
Сообщение: How to get array of unique array values across rows?