http://qs321.pair.com?node_id=11137452


in reply to Re: Research into occasional participation in Perl/Raku development
in thread Research into occasional participation in Perl/Raku development

hi rob, from the docs we have:

Coerces both arguments to Numeric (if necessary); returns True if they are equal. 
> my $x = 1/10;   #0.1
> $x.^name;       #Rat

> my  $y = 3602879701896397/36028797018963968;   #0.100000000000000006
> $y.^name;       #Rat

> $x == $y         #False   (no coercion necessary)
> $x == 0.1        #True     (no coercion necessary)
> $y == 0.1        #False   (no coercion necessary)
so comparing without coercion works as you expect

> 0.1e0.^name;  #Num
> $x == 0.1e0    #True    (coerces $x to Num, then compares)
> $y == 0.1e0    #True    (coerces $y to Num, then compares)

coercion from Rat to Num can result in loss of precision
> say $y.nude   #(3602879701896397 36028797018963968)
> say $y.Num    #0.1     
coercing this particular Rat to a Num collapses it to 0.1
IIRC the limit of Rat precision is e-14 ish (it gets lumpy), 
so in the general case it is fair to round away your ...00006 to 0
thus the Num 0.1 maps to both of these Rat options

[download]

your python example does much the same...

print (Fraction(3602879701896397, 36028797018963968) == 0.1); # True

Replies are listed 'Best First'.
Re^3: Research into occasional participation in Perl/Raku development
by syphilis (Archbishop) on Oct 13, 2021 at 00:25 UTC
    Coerces both arguments to Numeric (if necessary)...

    That's an unfortunate choice, IMO.

    coercion from Rat to Num can result in loss of precision

    And that's the reason that I don't like that choice. If instead, the Num was coerced to Rat, then there would be no loss of precision.

    your python example does much the same...

    If that were so, then I think the following python3 one-liner would print "True": 
    $ python3 -c 'from fractions import Fraction; print (Fraction(1,10) ==
+ 0.1);'
False

    [download]
    Even though the Fraction (Rat) 1/10 coerces to the float (Num) 0.1e0, python3 still recognizes that the 2 values are not equivalent.

    My only other experience with comparisons between rational types and floating point types is in the mpfr library where, like python3, the comparison is made between the "Rat" (mpq_t) and the exact rational value of the "Num" (mpfr_t) using the mpfr_cmp_q function.
    The gmp library has both a "Num" (mpf_t) and "Rat" (mpq_t) type, but doesn't provide any public functions for directly comparing the 2 types. It's therefore up to the user to come up with the comparison routines.

    Anyway, if raku users are happy with the approach taken then there's not much point in complaining about it.
    (And I haven't yet encountered any raku users that are unhappy with that current approach.)

    Cheers,
    Rob
[reply]
[d/l]

In Section Meditations