Re: Re: [GENERAL] Trouble with float4 afterupgrading from 6.5.3 to 7.0.2 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [GENERAL] Trouble with float4 afterupgrading from 6.5.3 to 7.0.2
Date
Msg-id 19770.965743484@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [GENERAL] Trouble with float4 afterupgrading from 6.5.3 to 7.0.2  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: Re: [GENERAL] Trouble with float4 afterupgrading from 6.5.3 to 7.0.2  (Don Baccus <dhogaza@pacifier.com>)
Re: Re: [GENERAL] Trouble with float4 afterupgrading from 6.5.3 to 7.0.2  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
Philip Warner <pjw@rhyme.com.au> writes:
> Given this, I have assumed that printf etc use these least significant bits
> to determine the 'correct' representation.

No.  What float4-to-text really does is *discard* information, by
rounding off the printed result to only 7 digits (when there are
actually 7-and-change in there).  This means values that are actually
distinct float4 values may get printed as the same thing:

regression=# select 1.234567 :: float4;
 ?column?
----------
  1.23457
(1 row)

regression=# select 1.234568 :: float4;
 ?column?
----------
  1.23457
(1 row)

regression=# select 1.234567 :: float4 = 1.234568 :: float4;
 ?column?
----------
 f
(1 row)

regression=# select 1.234567 :: float4 - 1.234568 :: float4;
   ?column?
--------------
 -9.53674e-07
(1 row)

I don't much care for this behavior (since it means dump and reload of
float columns is lossy), and I certainly won't hold still for
introducing it into other operations on floats.

            regards, tom lane

pgsql-hackers by date:

Previous
From: Philip Warner
Date:
Subject: Re: Re: [GENERAL] Trouble with float4 afterupgrading from 6.5.3 to 7.0.2
Next
From: Don Baccus
Date:
Subject: Re: Re: [GENERAL] Trouble with float4 afterupgrading from 6.5.3 to 7.0.2