Re: float8 auto truncation issue in ODBC v. PGSQL

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