Thread: Precision errors in float8 type casting (as of 7.3.2 and some earlier releases at least)
Precision errors in float8 type casting (as of 7.3.2 and some earlier releases at least)
From
Philip Edelbrock
Date:
I ran into this oddity today and tested it on a few of our PosgreSQL backends (all of which gave the same response): phil=# select 3.85::float4*1; ?column? ------------------ 3.84999990463257 (1 row) phil=# select 3.85::float4*1::float8; ?column? ------------------ 3.84999990463257 phil=# select (3.85::float4)::float8; float8 ------------------ 3.84999990463257 (1 row) (Or substitute 3.85 for any number with something other than 0 to the right of the decimal point, or pull the same values from any table which stores in float4/real format.) Obviously, this is wrong and should return 3.85. We traced this down on an ecom server which was shaving off pennies from some transactions (because we truncate to the hundredths place instead of rounding what we get back from the SQL backend). The newest server we have is 7.3.2, so I haven't tried this on the current 7.3.3 release. phil=# select version(); version --------------------------------------------------------------------------------------------------------- PostgreSQL 7.3.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) (1 row) Phil
On Wed, 9 Jul 2003, Philip Edelbrock wrote: > phil=# select (3.85::float4)::float8; > float8 > ------------------ > 3.84999990463257 > (1 row) > > (Or substitute 3.85 for any number with something other than 0 to the > right of the decimal point, or pull the same values from any table which > stores in float4/real format.) > > Obviously, this is wrong and should return 3.85. We traced this down on I see no obviously about it. Once you've placed a value in a float you are accepting the chance of some precision loss. When we print a float4 we can print it with an amount of precision that generally limits this (although you'll see things like 3.849998 -> 3.5), but once you cast it to a float8 those values are distinguishably different. In theory one could keep the history of the value around to determine a precision, but that doesn't really seem better in general.