I had thought that when raku compared a double with a rational, it would convert the double to its exact rational value, and then compare the 2 rationals.
Instead it apparently converts the rational to a double (rounding if necessary), and then compares the 2 doubles.

I've managed to satisfy myself that this is, in fact, what is going on. And based on this newfound wisdom, I've modified (and expanded) the original raku script that I provided so that it outputs no "not ok..." messages at all: 

my $d_1 = 0.1e0; # double   0.1 ( == 3602879701896397/3602879701896396
+8 )
my $r_1 = 0.1;   # rational 1/10

my $d_2 = 0.10000000000000001e0;# double, same value as $d_1
my $r_2 = 0.10000000000000001;  # rational 10000000000000001/100000000
+000000000

# check that $d_1 == 3602879701896397/36028797018963968
say "not ok 0" if $d_1 != 3602879701896397/36028797018963968;

# Check that $d_1 == 1 / 10
# This should be true because the RHS will be rounded to 0.1e0
say "not ok 1" if $d_1 != 1 / 10;

# Check that $d_1 and $d_2 are assigned to exactly the same value:
say "not ok 2" if $d_1 != $d_2;

# Check that $r_ and $r_2 are assigned different values:
say "not ok 3" if $r_1 == $r_2;

# Although $r_1 and $r_2 are unequal, $d_1 should be equal to both $r_
+1 && $r_2.
# This is because both $r_1 and $r_2 round to 0.1e0
# We check this, interchanging LHS and RHS operands in case that makes
+ a
# difference:
say "not ok 4" if ($d_1 != $r_1 && $d_1 != $r_2);
say "not ok 5" if ($r_1 != $d_1 && $r_2 != $d_1);

# Similarly $d_2 should be equal to both $r_1 and $r_2:
say "not ok 6" if ($d_2 != $r_1 && $d_2 != $r_2);
say "not ok 7" if ($r_1 != $d_2 && $r_2 != $d_2);

# The following 9 rationals should all round to 0.1e0.
# They equate to the 56-bit values:
# 0.11001100110011001100110011001100110011001100110011001100E-3
# 0.11001100110011001100110011001100110011001100110011001101E-3
# 0.11001100110011001100110011001100110011001100110011001110E-3
# 0.11001100110011001100110011001100110011001100110011001111E-3
# 0.11001100110011001100110011001100110011001100110011010000E-3
# 0.11001100110011001100110011001100110011001100110011010001E-3
# 0.11001100110011001100110011001100110011001100110011010010E-3
# 0.11001100110011001100110011001100110011001100110011010011E-3
# 0.11001100110011001100110011001100110011001100110011010100E-3

say "not ok 8"  if 14411518807585587/144115188075855872 != 0.1e0;
say "not ok 9"  if 57646075230342349/576460752303423488 != 0.1e0;
say "not ok 10" if 28823037615171175/288230376151711744 != 0.1e0;
say "not ok 11" if 57646075230342351/576460752303423488 != 0.1e0;
say "not ok 12" if 3602879701896397/36028797018963968   != 0.1e0;
say "not ok 13" if 57646075230342353/576460752303423488 != 0.1e0;
say "not ok 14" if 28823037615171177/288230376151711744 != 0.1e0;
say "not ok 15" if 57646075230342355/576460752303423488 != 0.1e0;
say "not ok 16" if 14411518807585589/144115188075855872 != 0.1e0;

# The following 2 rationals should not round to 0.1e0.
# They equate to the 56-bit values:
# 0.11001100110011001100110011001100110011001100110011001011E-3 (less 
+than 0.1 by 1ULP)
# 0.11001100110011001100110011001100110011001100110011010101E-3 (great
+er than 0.1 by 1ULP)

say "not ok 17" if 57646075230342347/576460752303423488 == 0.1e0;
say "not ok 18" if 57646075230342357/576460752303423488 == 0.1e0;

# Each of the 11 rationals just provided should be unequal to each oth
+er.
# We check this for a few (selected) values of these rationals.

say "not ok 19" if 14411518807585587/144115188075855872 == 57646075230
+342349/576460752303423488;
say "not ok 20" if 14411518807585587/144115188075855872 == 14411518807
+585589/144115188075855872;

say "not ok 21" if 14411518807585587/144115188075855872 == 57646075230
+342347/576460752303423488;
say "not ok 22" if 14411518807585589/144115188075855872 == 57646075230
+342357/576460752303423488;

[download]
And I think I understand the reasons (which are specified in the comments) that this particular script produces no output at all.
I don't agree with some of those reasons, though I don't rule out the possibility that the case is, at least, arguable.
And the documentation I found was full of all sorts of nomenclature/notation that I didn't understand.

There are, however, some additional aspects that I believe are nothing other than "weird buggery" - and I'll eventually report these "additional aspects" to the appropriate forum unless someone here likes to show me the errors in my thinking.
For example: 
> say 838861/8388608
0.10000002

[download]
How is that in any way accurate, helpful or useful ?
Neither as a rational nor a double does 838861/8388608 == 0.10000002 
> say 838861/8388608 == 0.10000002
False
> say 838861/8388608 == 0.10000002e0
False

[download]
The first interesting thing about the rational 838861/8388608 is that if you assign the value 0.1 to a 20-bit precision floating point data type, then the value assigned is exactly equivalent to 838861/8388608.
The second interesting thing is that, if you assign the value 0.10000002e0 to a 20-bit precision floating point data type, then you assign exactly the same value (ie 838861/8388608).
But, AFAIK, raku does not provide us with a 20-bit precision floating point type ... so why does it present us with a 20-bit precision floating point value ?
(I don't believe it would intentionally do that ... which is the reason that I'm thinking "bug".)
For mine, it would make far better sense to provide us with a value that can actually be verified: 
> say 838861/8388608 == 0.10000002384185791e0
True

[download]
Even more tantalizing: 
> say 56294995342131/562949953421312
0.0999999999999996
> say 56294995342131/562949953421312 == 0.0999999999999996
False
> say 56294995342131/562949953421312 == 0.0999999999999996e0
False

[download]
All it had to do was provide one additional decimal place: 
> say 56294995342131/562949953421312 == 0.09999999999999964e0
True

[download]
I have other similar examples.

Sorry - I probably should have placed my original post on this in the rants section.
I have no objections if someone wants to move this thread there.

Cheers,
Rob

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

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.