http://www.perlmonks.org?node_id=11130792


in reply to Re: [Raku] Arcane treatment of doubles and rationals
in thread [Raku] Arcane treatment of doubles and rationals

$ say 3602879701896397/36028797018963968 == 0.100000000000000006;
True


Have they changed the spec ?
> say 3602879701896397/36028797018963968 == 0.100000000000000006; False
I have:
$ raku -v Welcome to Rakudo(tm) v2021.03. Implementing the Raku(tm) programming language v6.d. Built on MoarVM version 2021.03.
If the RHS is a rational, then it's fairly easy to show that 3602879701896397/36028797018963968 != 100000000000000006/1000000000000000000.
(A/B == C/D if and only if A*D == B*C. In this case, A*D ends in zero and B*C ends in 8 so the equivalence cannot possibly hold.)

If the RHS is a double, then it's correct that 3602879701896397/36028797018963968 == 0.100000000000000006.
However, the 3 doubles assigned (respectively) the 3 values 0.100000000000000006, 0.10000000000000001 and 0.1 are all exactly the same. So we find, as expected:
> say 3602879701896397/36028797018963968 == 0.100000000000000006e0; True > say 3602879701896397/36028797018963968 == 0.10000000000000001e0; True > say 3602879701896397/36028797018963968 == 0.1e0; True
I've long been curious about the mindset that has created the rational/double arithmetic on raku, and I had thought (hoped) it might be a simple task to see how it all fits together.
Alas no, and I'm starting to see that I'm going to have to locate and work through the relevant documentation if I ever want to understand it.

Cheers,
Rob

Replies are listed 'Best First'.
Re^3: [Raku] Arcane treatment of doubles and rationals
by holli (Abbot) on Apr 04, 2021 at 12:59 UTC
    There is a loss of precision happening when using the exponential form.
    $ raku -e "dd 0.10000000000000006e0" 0.10000000000000006e0 $ raku -e "dd 0.100000000000000006e0" 0.1e0
    The exponential form creates a Num which needs to be between -1.7976931348623157e308 to 1.7976931348623158e308. See what Raku considers Infinity.


    holli

    You can lead your users to water, but alas, you cannot drown them.
      I'd consider this a bug

      Yes, I think there's something that's definitely not right.
      For a start, there's never any need to assign an 18-significant-digit (decimal) value to a double.
      Whatever value is assigned to a double by the 18-siginificant-digit 0.100000000000000006 will also be assigned by the 17-significant-digit 0.10000000000000001.

      As I said (in the reply to myself that I posted shortly after your post), I will raise the issues with them.

      Cheers,
      Rob
        there's never any need to assign an 18-significant-digit (decimal) value to a double
        You are forcing that by using an exponent.


        holli

        You can lead your users to water, but alas, you cannot drown them.