Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Re^4: int() function

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

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

> if the stringification provided an extra 2 decimal digits

How this? There are only 2-3 bits left and 2**3 < 10, so no way to get a 16th decimal out of a double.

I know it's confusing. But if you stuff a number with more than 15 decimals into a double you'll have loss anyway. And I doubt it's better in JS or python.

> "cmp_ok(0.14, '==', 1.4 / 10

Well, but on the other hand eq should work because of the magic.

IMHO most people understand rounding errors, the point of confusion is that exact decimal fractions are not always exact binarie floats.

Probably we should have a shortcut for something like printf "%.18f" to facilitate diagnosis.

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

Replies are listed 'Best First'.
Re^5: int() function
by syphilis (Bishop) on Oct 25, 2020 at 13:05 UTC
    I know it's confusing

    I don't find it so.

    But if you stuff a number with more than 15 decimals into a double you'll have loss anyway.

    One thing I can guarantee is that if you limit yourself to 15 decimal digits, you will experience the loss of not being able to assign the full range of "double" values.
    As an example:
    C:\perl -le "printf '%a', 1.41421356237312;" 0x1.6a09e667f3c3dp+0 C:\>perl -le "printf '%a', 1.41421356237313;" 0x1.6a09e667f3c6ap+0
    Between 0x1.6a...c3d and 0x1.6a...c6a there exists 45 doubles with distinct, precise values. (c6a - c3d == 2d == 45 in base 10)
    But you can't assign to any of those 45 values if you limit yourself to assigning 15-digit values. (For some of those values 16 digits will suffice, but you'll never need more than 17 digits.)
    Also, for each of those 45 values, perl will output that they are either 1.41421356237312 or 1.41421356237313.
    That's 45 precise, distinct, unique values - for which perl will display only 2 values.
    Perl is making itself look ridiculous for the sake of saving 2 digits of precision.

    And I doubt it's better in JS or python

    Python2 was crap, but python3 (as I've already mentioned in this thread) is exemplary:
    $ python3 -c "print(0.14)" 0.14 $ python3 -c "print(1.4 / 10)" 0.13999999999999999 $ python3 -c "print(2 ** 0.5)" 1.4142135623730951
    Python3 will always output the minimum number of decimal digits needed to preserve the uniqueness of the given value. And, last time I checked, raku was outputting exactly the same as python3 - for "doubles", anyway.

    Not sure what happens with javascript - I've no experience with it.

      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

        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.


Log In?

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

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (3)
As of 2021-04-23 03:28 GMT
Find Nodes?
    Voting Booth?

    No recent polls found