in reply to Re^2: Windows / Linux puzzler
in thread Windows / Linux puzzler

Hmmmmmmmmmmmmmmmmmmmm...

I think Veltro's point is likely irrelevant if both the Windows perl and Linux perl report the same value for $Config{nvsize}.
But if the nvsize differs between the 2 perls, then it's a different matter. For example: 
On perl-5.30.0 whose nvsize is 8 (and whose nvtype is 'double':
C:\>perl -V:nvsize
nvsize='8';

C:\>perl -le "print int(1000 * 0.001);"
1

On perl-5.30.0 whose nvsize is 12 or 16 (and whose nvtype is 'long dou
+ble'):
C:\>perl -V:nvsize
nvsize='16';

C:\>perl -le "print int(1000 * 0.001);"
0

[download]
Does perl -V:nvsize report the same value on both machines ?
Does perl -V:nvtype report the same type on both machines ?

Update: It's probably worth mentioning that both of those perls are correct in what they're doing.
The double that most closely represents the value 0.001 is actually slightly greater than 0.001
The long double that most closely represents the value 0.001 is actually slightly less than 0.001.

Cheers,
Rob

Replies are listed 'Best First'.
Re^4: Windows / Linux puzzler
by ikegami (Patriarch) on Mar 25, 2020 at 18:45 UTC

    I think Veltro's point is likely irrelevant if both the Windows perl and Linux perl report the same value for $Config{nvsize}.

    In at least some verisons of Perl, creating a float from a string is done by the underlying C library, and MS's library is known to not be as good as a gcc's.

    Image showing the output varies by compiler

    I didn't include nvsize in the screenshot, but both builds use IEEE double-precision floats.

[reply]
      MS's library is known to not be as good as a gcc's


      All that the linked example demonstrates is that there's a discrepancy in the %.20g formatting - it says nothing about the ability to assign values correctly.
      If you compare the actual values by doing "%a" formatting on both the Linux and windows perls, you'll see that 0.1 is exactly the same double.
      Also, I believe the OP's activestate perl was built with (mingw port of) gcc. They stopped using Microsoft compilers a few years ago.

      ikegami's point is likely even more irrelevant than Veltro's.

      Cheers,
      Rob
[reply]

        If you compare the actual values by doing "%a" formatting on both the Linux and windows perls, you'll see that 0.1 is exactly the same double.

        Your are correct. pack 'd' shows this more definitely. 

        >perl -E"say sprintf '%vX', pack 'd>', $ARGV[0]" 0.1
3F.B9.99.99.99.99.99.9A

        [download]
        $ perl -E'say sprintf "%vX", pack "d>", $ARGV[0]', 0.1
3F.B9.99.99.99.99.99.9A

        [download]

        I believe the OP's activestate perl was built with (mingw port of) gcc

        It definitely allows mingw to be used to compile modules, but I don't know if that's what used to build Perl itself. (Update: perl -V hints that it uses mingw)

        I beleive Strawberry Perl uses mingw, and I used Strawberry Perl in the test in the earlier post. If so, there are pertinent differences in the libraries between mingw and gcc.

[reply]
[d/l]
[select]
Re^4: Windows / Linux puzzler
by lbrandewie (Acolyte) on Mar 24, 2020 at 06:42 UTC

    Hey Rob,

    Thanks for the reply. Both versions of perl report nvsize at 8. But, I have no clue what the significance of this value is. Could you please explain?

    Thanks,

    Lars

[reply]
      Could you please explain?

      "NV" is just the term used for perl's floating point type.
      Depending upon how perl was built, it could be either a 'double', a 'long double', or a '__float128'.
      $Config{nvtype} tells you which type the NV is.
      $Config{nvsize} tells you how many bytes are allocated to that particular type.

      If nvtype and nvsize don't change from one machine to the other (as is the case with your machines) then arithmetical operations should produce identical results.
      If the configurations match (wrt nvsize and nvtype) and identical arithmetic operations produce different results, then at least one of those machines has a bug.
      Such bugs do exist - but they're relatively rare. (On perl-5.30.0 they're even rarer.)

      Cheers,
      Rob
[reply]

In Section Seekers of Perl Wisdom