Re: float8 auto truncation issue in ODBC v. PGSQL

["Campbell, Greg" <greg(dot)campbell(at)us(dot)michelin(dot)com>]

My comments were general more than specific to our situation.

I work with some legacy systems that are quite old (80'x unix, OpenVMS, IBM mainframes).
I have built MessageQ-ing application and discover the structures of floating points were not reliably 
simple transfers. The original programs (in Fortran and Pascal) may have using specification called 
F-floating point, and G-floating point. There might be correlation to IEEE 754 OR IEEE 854, depending on 
size (16,32,64 bit).

So as a policy, I use comparison of Abs(x-y) < 0.0001 instead of expecting exact 1.475 and being surprised 
to fine 1.47500000001. I realize it might not apply as I pull PostgreSQL from a Linux box into say a VB6 
application.






Marc Herbert wrote:
> "Campbell, Greg" <greg(dot)campbell(at)us(dot)michelin(dot)com> writes:
>
>
> > I've disassociated floats and exactness, that is floating point
> > representations and exact matches do not seem to go together.
>
>
> The issue is that "float" types actually means fractions encoded in
> base 2 for efficiency reasons. Almost every time you go back and forth
> between base 2 and base 10 you have to round, there is no exact
> mapping between those two spaces.
>
> For instance you can not write 1/3 (one third) in base 10 whereas you
> can in base 3 using just a couple of digits (it's just "0.1")
>
>
>
> > The idea was made more profound when I started looking into the
> > multitude of options in representing a float in 16, 32 or 64
> > bits. There are so many different ways to allocate bits for the
> > number, and bits for the exponent, leading to radically different
> > precisions.
>
>
> Actually on today's hardware I thought it was hard to find anything
> else than IEEE754 32 and 64 bits floats, standardized across all
> platforms, and 32 bits values being a subset of 64 bits. So that does
> not look like "many different ways" to me. Could you detail?
>
>
>
> > Between a value
> > on the server and a value on the client a difference out in the 15th
> > decimal place hardly seems surprising.
>
>
> Whether conversions and roundings happen on the server on or the
> client does not seem to change the problem much IMHO.
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>        message can get through to the mailing list cleanly
begin:vcard
fn:Greg Campbell
n:Campbell;Greg
org:Michelin North America - US5 Lexington;ENG-ASE
email;internet:greg(dot)campbell(at)us(dot)michelin(dot)com
title:ASE Systems Engineer
tel;work:803-951-5561/x75561
x-mozilla-html:FALSE
version:2.1
end:vcard