Re: Floating point error - Mailing list pgsql-general

From Tom Duffey
Subject Re: Floating point error
Date
Msg-id B8EB2D29-930C-485C-BAEC-70741A80ED1C@trillitech.com
Whole thread Raw
In response to Re: Floating point error  (James Cloos <cloos@jhcloos.com>)
Responses Re: Floating point error
Re: Floating point error
List pgsql-general
Hi Everyone,

To bring closure to this thread, my whole problem was caused by not knowing about the extra_float_digits setting. We
havea script that uses COPY to transfer a subset of rows from a very large production table to a test table. The script
wasnot setting extra_float_digits so the values did not match even though they appeared to match when running queries
inpsql. Definitely another gotcha for floating point values and it might be a good idea to mention this setting on the
"NumericTypes" page of the docs. 

Thanks to all who chimed in to help!

Tom

On Feb 28, 2013, at 7:05 PM, James Cloos <cloos@jhcloos.com> wrote:

>>>>>> "TD" == Tom Duffey <tduffey@trillitech.com> writes:
>
> TD> Riddle me this. I have a database column of type "real" that gets
> TD> mapped to a Java field of type double via JDBC. ...
>
> TD> - Selecting values from both test and production DBs using psql
> TD>   shows "10.3885" as the value
>
> TD> - The Java app on production shows "10.3884573" while the test app
> TD>   shows "10.3885"
>
> I suspect the issue is that psql(1) and whatever java method you use to
> convert the floats to text choose different rounding.
>
> By default, it seems that psql(1) uses something like printf("%.4f",...)
> whereas your java app calls a routing which works more like "%.7f".
>
> (The wire format for floats is the same as they are stored, not a text
> representation thereof.)
>
> -JimC
> --
> James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

--
Tom Duffey
tduffey@trillitech.com
414-751-0600 x102



pgsql-general by date:

Previous
From: James Cloos
Date:
Subject: Re: Floating point error
Next
From: bhanu udaya
Date:
Subject: GetHierarchy