I admire Peter's effort in tracking down the specifics at various conversion points.
However, there are no documented guarantees of equality from the library. I hope you're not seriously considering jigging the libraries to make your program work. If you do that, you'll run up against the same problem next release. The more stable solution would be to change your program so it doesn't depend on equality. Rather you could create a function floatEqual() or floatZero() that tests whether two float values are nearly equal in relative terms, or close to zero, without requiring that they be exactly equal or zero. Then replace the == operator in your application code with those function calls. I bet it would be less work to use that solution than to jig the libraries. Besides, there are many floating point conversion points, including the compiler itself, that can change with a new release. -Will > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Erwan Lemonnier > Sent: Wednesday 11 July 2007 04:29 > To: [email protected]; [EMAIL PROTECTED] > Subject: Re: Re: float bug? perl 5.8, DBI and oracle 10.2.0 > > > Taking up on Peter's answer to > http://www.nntp.perl.org/group/perl.dbi.users/2007/07/msg31663.html: > > > This is peculiar, though. DBD::Oracle gets the number from > the database > > as a string (this can be confirmed with Devel::Peek::Dump), > so the above > > code should be equvialent to: > > > > my ($val) = ('1.73696'); > > > > my $sum = 1.73696 - $val; > > is($sum,0,"does sum $sum == 0?"); > > That's indeed what I thought. I tried. But as you mention > below, it isn't. > > > However, it isn't, for some reason, and I can't see the difference > > (upgrading $val to utf8 doesn't make a difference). > > > > Why does perl convert the string '1.73696' to > > > > 0011111111111011110010101001011010010001101001110101110011010000 > > > > if it comes from an Oracle database, but convert it to > > > > 0011111111111011110010101001011010010001101001110101110011010001 > > > > if it is hard coded in the script or read from a file? > > Thanks! I think you just put your finger on the core of the problem! > This is the very reason why I turned toward the DBI list in the first > hand. > > Note that the trailing bit is most probably the one that gets > interpreted as 2^-52 (2.22044604925031e-16) in the faulty $sum result. > > I would like to check what binary representation perl 5.6.2 returns > for that same string when fetched from the database. How did you get > the binary strings above? > It itches me that the computation gives the correct result in perl > 5.6.2 but not 5.8.8. > > The next question would be: what is in charge of converting the data > representation fetched from oracle into perl's native float (leading > to the binary representation you listed above). Would that be > DBD::Oracle? or DBI? or perl itself? > > /Erwan Lemonnier > - - - - - Appended by Scientific Atlanta, a Cisco company - - - - - This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.
