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

\$ say 3602879701896397/36028797018963968 == 0.100000000000000006;
True

Have they changed the spec ?
```> say 3602879701896397/36028797018963968 == 0.100000000000000006;
False
[download]```
I have:
```\$ raku -v
Welcome to Rakudo(tm) v2021.03.
Implementing the Raku(tm) programming language v6.d.
Built on MoarVM version 2021.03.
[download]```
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
[download]```
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
[download]```
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.