Skip site navigation (1) Skip section navigation (2)

Re: float8 auto truncation issue in ODBC v. PGSQL

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 (view raw or flat)
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: greg.campbell.vcf
Description: text/x-vcard (241 bytes)

In response to

pgsql-odbc by date

Next:From: Hiroshi InoueDate: 2006-06-14 21:28:59
Subject: Re: Patch for snprintf problem (bug #1000650) 5-th try
Previous:From: ricarddDate: 2006-06-14 20:55:31
Subject: Re: UNRESOLVED: odbc driver manager and postgresql odbc

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group