Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re^6: int() function

by LanX (Cardinal)
on Oct 25, 2020 at 18:21 UTC ( #11123159=note: print w/replies, xml ) Need Help??


in reply to Re^5: int() function
in thread int() function

We seem to have different priorities.

If there is a 16th decimal digit printed I expect it to be correct in any case.

Maybe one of those dump commands should be included into core to help clarifying what's happening by using printf '%.17f' for floats.

Raku's solution seems far better than the Py3 one, because people expect decimal DWIM.

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery

Replies are listed 'Best First'.
Re^7: int() function
by syphilis (Bishop) on Oct 26, 2020 at 02:28 UTC
    Raku's solution seems far better than the Py3 one, because people expect decimal DWIM

    I don't expect (or even want) "decimal DWIM" of NVs ... which, indeed, says something about the different priorities that you and I have.
    And I've no objection to raku's propensity for rational arithmetic.

    However, raku does allow for floating point values (doubles), and if you get raku to print these values you will find that they generally provide the same as py3:
    $ python3 -c "print (2 ** 0.5)" 1.4142135623730951 $ rakudo -e "say 2 ** 0.5;" 1.4142135623730951 $ perl -le "print 2 ** 0.5;" 1.4142135623731
    AIUI, both python3 and raku use the grisu3 algorithm, which is pretty quick. However grisu3 is not suitable for all values, and when such values are encountered raku falls back to sprintf("%.17g", ..) formatting.
    Py3 apparently falls back to the "dragon4" algorithm. (Not exactly sure of what python3 does.)
    I've gleaned most of that from a post by Zoffix, and from other comments he has made (but that I can't locate).
    But you'll find that, for those values where grisu3 fails, raku produces "%.17g" formatting whereas py3 might output less than 17 digits.
    I know that no-one's particularly interested, but here's an example of what happens when the double that has been assigned the value 5.3130431399669280e-34 is printed.
    On raku, grisu3 fails, and we fall back to "%.17g" formatting:
    $ rakudo -e "say (5.3130431399669280e-34)" 5.3130431399669284e-34
    With py3:
    $ python3 -c "print (5.3130431399669280e-34)" 5.313043139966928e-34
    And perl:
    $ perl -le "print 5.3130431399669280e-34;" 5.31304313996693e-34
    Perl's output is the only one I find objectionable because it's the only one of the 3 different outputs that doesn't assign to the original value.

    The one noteworthy thing about 15-digit decimals is that, if the digits differ, then the values of the doubles that they assign to also differ.
    So, eg, you will know just by looking that the 15-digit decimals 12345678901234.1 and 12345678901234.2 assign to different doubles.
    But as soon as you go beyond 15-decimal digits, that assurance is lost. For example, with 16 digits, 9.007199254740993e+15 and 9.007199254740992e+15 assign to exactly the same double, even though the digits differ.

    Cheers,
    Rob
      "%.17g" formatting

      I was surprised to see 16 digits after the decimal point in a "%.17" notation. Per perl's sprintf docs:

      %g    a floating-point number, in %e or %f notation

      But that's not what actually happens in Perl:

      C:>perl -MConfig -le "print +5.3130431399669280e-34; printf qq($_\n), ++5.3130431399669280e-34 for qw/%.17f %.17e %.17g/; print qq($^V\t|\t$ +Config{myuname})" 5.31304313996693e-34 0.00000000000000000 5.31304313996692843e-34 5.3130431399669284e-34 v5.30.0 | Win32 strawberry-perl 5.30.0.1 #1 Thu May 23 12:20:46 +2019 x64

      ... In this instance, "%.17g" is neither equivalent to "%.17f" (17 digits after the fixed decimal point) nor to "%.17e" (17 digits after the floating decimal point).

      I tried on an ancient linux machine with v5.8.5, with similar results:

      % perl -MConfig -le 'print +5.3130431399669280e-34; printf qq($_\n), + +5.3130431399669280e-34 for qw/%.17f %.17e %.17g/; print qq($]\t|\t$Co +nfig{myuname})' 5.31304313996693e-34 0.00000000000000000 5.31304313996692843e-34 5.3130431399669284e-34 5.008005 | linux builder4.centos.org 2.6.9-55.0.9.elsmp # +1 smp thu sep 27 18:27:41 edt 2007 i686 i686 i386 gnulinux

      The sprintf docs have used that phrasing at least as far back as v5.005 . Am I misunderstanding what I'm seeing? or has perl documentation about %g been wrong for that long?

        %g a floating-point number, in %e or %f notation

        The full piece of documentation is:
        %e a floating-point number, in scientific notation %f a floating-point number, in fixed decimal notation %g a floating-point number, in %e or %f notation
        I think the last of those 3 is just shorthand for:
        %g a floating-point number, in scientific notation or fixed decima +l notation
        Note that "%.*g" will give you scientific notation and "%*g" will give you fixed decimal notation (ie fixed to 6 digits of precision).
        I think it's just meant to provide a quick indication of what "%g" formatting does, for anyone who is unfamiliar with it.
        Those are the only excuses I can come up with ;-)

        Cheers,
        Rob

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11123159]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (7)
As of 2021-01-21 12:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?