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
.

Relevant Pages