Converting -4.84800000E+001 to -48.48 doesn't work... but 48.49 does

notameadow has asked for the wisdom of the Perl Monks concerning the following question:

Hello, I have just spent better part of the day trying to work this out. It looks like a bug, but that would be quite interesting in itself. Try this:

perl -e '$a = "-4.84900000E+001"; $a += 0; $b = -48.49; print "EQ\n" i
+f ($a == $b); print "$a\n$b\n";'
[download]

it gives:

EQ
-48.49
-48.49
[download]

All good. Now, try this:

perl -e '$a = "-4.84800000E+001"; $a += 0; $b = -48.48; print "EQ\n" i
+f ($a == $b); print "$a\n$b\n";'
[download]

gives:

-48.48
-48.48
[download]

? In my main code I am getting scientific notation values as strings, I add 0 and compare them as numbers. It all works, but not for -4.84800000E+001 (and 4.84800000E+001 too). Why? I tried some combinations like 37.37 and so on.

perl -v
This is perl 5, version 22, subversion 2 (v5.22.2) built for x86_64-li
+nux-thread-multi
(with 33 registered patches, see perl -V for more detail)
[download]

I really do hope this is something silly on my part.

Comment on Converting -4.84800000E+001 to -48.48 doesn't work... but 48.49 does Select or Download Code

Replies are listed 'Best First'.
Re: Converting -4.84800000E+001 to -48.48 doesn't work... but 48.49 does by choroba (Cardinal) on Jan 05, 2017 at 20:44 UTC
As usually, the inner representation of the numbers is different: `my $x = "-4.84800000E+001"; $x += 0; my $y = -48.48; print "EQ\n" if $x == $y; printf "%.16f\n%.16f\n", $x, $y; __END__ -48.4800000000000040 -48.4799999999999969` [download] See also What Every Programmer Should Know About Floating-Point Arithmetic. ($q=q:Sq=~/;[c](.)(.)/;chr(-\|\|-\|5+lengthSq)`"S\|oS2"`map{chr \|+ord }map{substrSq`S_+\|`\|}3E\|-\|`7**2-3:)=~y+S\|`+$1,++print+eval$q,q,a, [download]	[reply] [d/l] [select]
Re: Converting -4.84800000E+001 to -48.48 doesn't work... but 48.49 does by AnomalousMonk (Archbishop) on Jan 05, 2017 at 21:11 UTC
The problem also seems related to Perl version, but I can't say why. Trying the following code under various Perl versions I have access to ATM: `c:\@Work\Perl\monks>perl -wMstrict -le "print 'perl version: ', $]; ;; $a = '-4.84800000E+001'; $a += 0; $b = -48.48; print 'EQ' if $a == $b; printf qq{%0.20f ?==? %0.20f \n}, $a, $b; " perl version: 5.008009 -48.48000000000000400000 ?==? -48.47999999999999700000 perl version: 5.010001 EQ -48.47999999999999700000 ?==? -48.47999999999999700000 perl version: 5.014004 EQ -48.47999999999999700000 ?==? -48.47999999999999700000` [download] Update: choroba has `/msg`d to ask if the differences in my results are due to 32- versus 64-bit build differences. As far as I can see from `perl -V` (and to the best of my recollection), all the Perls I have here are 32-bit. However, the 5.8.9 I'm using is ActiveState, while the others are all Strawberries. Update: davido `/msg`d to suggest different C compilers/libraries have different internal implementations for FP handling; perhaps AS Perl was compiled with Visual Studio and Strawberry with GNU/C. Give a man a fish: `<%-{-{-{-<`	[reply] [d/l] [select]
Re^2: Converting -4.84800000E+001 to -48.48 doesn't work... but 48.49 does by syphilis (Archbishop) on Jan 05, 2017 at 22:44 UTC
The problem also seems related to Perl version, but I can't say why It's a known bug. For your particular example (on Win32, perl-5.22.0): `C:>perl -le "print scalar reverse unpack 'h', pack 'd<', -48.48;" c0483d70a3d70a3d C:>perl -le "print scalar reverse unpack 'h', pack 'd<', -4.848e1;" c0483d70a3d70a3e` [download] -48.48 is being assigned correctly, but -4.848e1 is off by one ulp. These errors are not uncommon and can change between perl versions. Cheers, Rob	[reply] [d/l]
Re^3: Converting -4.84800000E+001 to -48.48 doesn't work... but 48.49 does by Anonymous Monk on Jan 06, 2017 at 00:39 UTC
These errors are not uncommon and can change between perl versions. And C libraries and compilers and even seemingly-unrelated compiler settings.	[reply]
Re^4: Converting -4.84800000E+001 to -48.48 doesn't work... but 48.49 does by syphilis (Archbishop) on Jan 06, 2017 at 03:37 UTC
Re^5: Converting -4.84800000E+001 to -48.48 doesn't work... but 48.49 does (clever) by tye (Sage) on Jan 07, 2017 at 19:06 UTC
Some notes below your chosen depth have not been shown here
Re: Converting -4.84800000E+001 to -48.48 doesn't work... but 48.49 does by LanX (Saint) on Jan 05, 2017 at 23:37 UTC
Computers can't be accurate with all fractions because Humans have too many fingers . update Now unfortunately the calculation path to the inner representation of 48.48 and 4.848e1 seem to produce different results. Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :) Je suis Charlie!}	[reply]
Re^2: Converting -4.84800000E+001 to -48.48 doesn't work... but 48.49 does by syphilis (Archbishop) on Jan 05, 2017 at 23:54 UTC
Computers can't be accurate with all fractions But this is no excuse for -4.848e1 and -48.48 being treated as different values. Cheers, Rob	[reply]
Re^3: Converting -4.84800000E+001 to -48.48 doesn't work... but 48.49 does by Laurent_R (Canon) on Jan 06, 2017 at 07:27 UTC
Yes, sure, this is not satisfactory, but the bottom line, in C, in Perl and in most other programming languages, is that you should not compare floats for equality (unless you really know very well what you're doing). To check is two such numbers shall be deemed equal, one should check that the absolute value of their difference is smaller than a certain very small value. Perl 6 has a rational type, in which numbers are stored internally as a numerator and a denominator, allowing for accurate comparison of decimal numbers.	[reply]
Re^3: Converting -4.84800000E+001 to -48.48 doesn't work... but 48.49 does by LanX (Saint) on Jan 06, 2017 at 00:03 UTC
Yeah just updated it before I saw your reply. I think the way -48.48 is transformed into a float follows a different calculation path which rounds the last bit into another direction. Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :) Je suis Charlie!}	[reply]
Re: Converting -4.84800000E+001 to -48.48 doesn't work... but 48.49 does by notameadow (Initiate) on Jan 06, 2017 at 09:03 UTC
Thanks for all your help. I was only vaguely aware of how tricky comparing floats that looked quite round can be. Unfortunately one side of comparison is supplied by humans and the other is coming back from a device and I have no influence on neither, so will have to rely on rounding the machine side to 2f. Thanks again.	[reply]

update