From: | Marc Herbert <Marc(dot)Herbert(at)continuent(dot)com> |
---|---|
To: | pgsql-odbc(at)postgresql(dot)org |
Subject: | Re: float8 auto truncation issue in ODBC v. PGSQL |
Date: | 2006-06-14 18:44:24 |
Message-ID: | khj1wtrtw53.fsf@meije.emic.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-odbc |
"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.
From | Date | Subject | |
---|---|---|---|
Next Message | ricardd | 2006-06-14 19:37:04 | UNRESOLVED: odbc driver manager and postgresql odbc driver in Ubuntu |
Previous Message | Andrus | 2006-06-14 17:27:30 | Page fault on connection |