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

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 /msgd 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 /msgd 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:  <%-{-{-{-<

Replies are listed 'Best First'.
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]
      These errors are not uncommon and can change between perl versions.
      And C libraries and compilers and even seemingly-unrelated compiler settings.
[reply]
        And C libraries and compilers and even seemingly-unrelated compiler settings.

        I strike these errors more in perl than in anything else. (But then, I only ever use perl and C ;-)
        If you know of any such error with the mpfr C library, please report it to the mpfr at loria.fr list.

        I think Jarkko Hietaniemi plans to replace perl's current (homegrown) implementation with netlib's gdtoa ... if he manages to find the tuits.
        It would therefore be a good idea to report any problems with gdtoa to p5p.

        Cheers,
        Rob
[reply]

In Section Seekers of Perl Wisdom