From: | "Campbell, Greg" <greg(dot)campbell(at)us(dot)michelin(dot)com> |
---|---|
To: | Marc Herbert <Marc(dot)Herbert(at)continuent(dot)com> |
Cc: | pgsql-odbc(at)postgresql(dot)org |
Subject: | Re: float8 auto truncation issue in ODBC v. PGSQL |
Date: | 2006-06-14 21:07:18 |
Message-ID: | 44907A86.4010306@us.michelin.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-odbc |
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
Attachment | Content-Type | Size |
---|---|---|
greg.campbell.vcf | text/x-vcard | 241 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2006-06-14 21:28:59 | Re: Patch for snprintf problem (bug #1000650) 5-th try |
Previous Message | ricardd | 2006-06-14 20:55:31 | Re: UNRESOLVED: odbc driver manager and postgresql odbc |