Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re: [Raku] Arcane treatment of doubles and rationals

by holli (Abbot)
on Apr 03, 2021 at 22:41 UTC ( #11130786=note: print w/replies, xml ) Need Help??

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

display the fact that the (double precision) values held by $d_1 and $d_2 are exactly equivalent to the rational value 3602879701896397/36028797018963968
I think your assumption is wrong.
$ say 3602879701896397/36028797018963968 == 0.100000000000000006; True $ say 10000000000000001/100000000000000000 == 0.10000000000000001 == 0 +.10000000000000001e0 == 0.1 + 1e-18; True

== and the other operators don't care about the type of the number they work with, they will coerce every operand to Num anyway. However
$ say 3602879701896397/36028797018963968 =~= 0.10000000000000001; True
There is also a unicode variant of the approximately-equal operator but it won't display correctly here.


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

Replies are listed 'Best First'.
Re^2: [Raku] Arcane treatment of doubles and rationals
by syphilis (Bishop) on Apr 04, 2021 at 00:24 UTC
    $ say 3602879701896397/36028797018963968 == 0.100000000000000006;

    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.

      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.


      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.


Log In?

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

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2021-09-23 00:34 GMT
Find Nodes?
    Voting Booth?

    No recent polls found