From zefram@fysh.org

I can vacuously subclass Num and instantiate my new class with specific
floating-point values, and this generally works. The subclassed numbers
correctly compare == and !=== to the base Num of the same floating-point
value​:

my $three = (my class MyNum is Num {}).new(3e0); say $three.WHICH; say $three == 3e0; say $three === 3e0
MyNum|3
True
False

But there's a problem with NaN. It correctly compares != to the base NaN
(per usual numeric comparison semantics, and correctly has a different
.WHICH reflecting its different class, but bizarrely it compares ===
to the base NaN​:

my $mynan = (my class MyNum is Num {}).new(NaN); say $mynan.WHICH; say $mynan == NaN; say $mynan === NaN
MyNum|NaN
False
True

=== on NaNs should pay attention to the class, in the same way that ===
on non-NaN Num values does.

-zefram

From @zoffixznet

On Fri, 19 Aug 2016 15​:40​:36 -0700, zefram@​fysh.org wrote​:

I can vacuously subclass Num and instantiate my new class with
specific
floating-point values, and this generally works. The subclassed
numbers
correctly compare == and !=== to the base Num of the same floating-
point
value​:

my $three = (my class MyNum is Num {}).new(3e0); say $three.WHICH;
say $three == 3e0; say $three === 3e0
MyNum|3
True
False

But there's a problem with NaN. It correctly compares != to the base
NaN
(per usual numeric comparison semantics, and correctly has a different
.WHICH reflecting its different class, but bizarrely it compares ===
to the base NaN​:

my $mynan = (my class MyNum is Num {}).new(NaN); say $mynan.WHICH;
say $mynan == NaN; say $mynan === NaN
MyNum|NaN
False
True

=== on NaNs should pay attention to the class, in the same way that

on non-NaN Num values does.

-zefram

Thank you for the report. This is now fixed.

I suspect it was fixed a while back, when issues with NaNs were sorted out.
Test added​: Raku/roast@860dc71980

The RT System itself - Status changed from 'new' to 'open'

@zoffixznet - Status changed from 'open' to 'resolved'