in reply to Re: Re: Re: Filthy Floats
in thread Filthy Floats

Perl does lots of magic, especially in the way it handles scalars as strings, integers and floats simultaneously.

In your case, the value is being handled as a string until you force Perl to treat it as a number (by using it in a multiplication). The result is a floating point value, subject to the inaccuracies described elsewhere. If it comes up with a seemingly exact value sometimes, well, welcome to the mystery :)

I take it the issue here is that you want a leading zero, or some other normalization? If so, then use sprintf to enforce the format you want. Try <%=sprintf("%1.2f",$target)%> for instance.

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Filthy Floats
by THuG (Beadle) on Jul 16, 2001 at 21:22 UTC

    No, I don't want normalization, what I want is the number that was put into the DB. If they put in .98, then I want .98. If they put in .97062, then that's what I want.

    If I give Perl .98 as a string and then coherce it into a float, it has no problem representing it. I simply fail to believe that there is a floating point precision problem within Perl that should be accepted in this case. There may be one in Access, or in the ODBC magic that is handing the data to Perl from the DB. In other words, if there is a floating point problem, it is correctable on some level.

    -Travis

[reply]
      Then store the value as a string, an integer, or something else that will remain exact. If you put it in a floating point value (in Perl, Access, ODBC or whatever) then you will not get the exact value back, except in cases where the binary and decimal representations have the same value (such as zero).

      As to the second point, this is not correctable, on any level. You can get closer to exact values by using more bits (thus the attraction of double over float) but the phenomenon is inherent to floating point representation in binary, not to any of the languages mentioned.

[reply]

In Section Seekers of Perl Wisdom