On Wed, 22 Feb 2017 19:32:31 -0800, comdog wrote:
> Here's a curious change over in precision:
>
> > 4.999999999999999 ~~ 0..^5
> True
> > 4.9999999999999999 ~~ 0..^5
> False
>
> I figure this is an implementation detail that ties to storage, but
> one of the selling points of Perl 6 is that this sort of thing isn't
> a problem anymore.
>
> > $*PERL
> Perl 6 (6.c)
> > $*VM
> moar (2017.01)
There are two issues at play here:
1) `cmp` with Rationals with Rational/Ints was busted and was using Num
precision.
This is now fixed[^1] and tested[^2], so `4.9999999999999999 ~~ 0..^5`
does give True
2) My reading of the ticket suggests that you'd expect
`4.99999999999999999999999 ~~ 0..^5` to give
True as well, however, you'll notice that won't be the case, even after the
fix in (1). The
reason is such a number is too big to fit into a Rat. If you dump its
components, you'll see
the loss in precision:
<Zoffix> m: dd 4.99999999999999999999999
<camelia> rakudo-moar 9e8ecb: OUTPUT:
«<499999999999999999999999/99999999999999991611392>»
And it's that loss that would give the wrong answer when `cmp` it it or
smartmatching with it.
That behaviour is LTA and when we'd use proper uint64 for components,
things would be even worse.
There was a discussion[^3] on the topic today and one of the proposals was
to create a RatStr
allomorph in such cases which would basically behave as a non-infectious
FatRat. I'll give that
idea a go in the next few days (though I have a hunch 6.c tests would
block this until 6.d).
You don't have to wait for resolution of that issue, however, and can make
a RatStr yourself, using
angled brackets:
<Zoffix> m: say <4.99999999999999999999999999999999999999999999> ~~
0..^5
<camelia> rakudo-moar 9e8ecb: OUTPUT: «True»
It produces the right result.
[1]
https://github.com/rakudo/rakudo/commit/9e8ecb7bacedc8845dcf4b290aae431b00ba7e7c
[2]
https://github.com/perl6/roast/commit/31d9af38842748798a720b0e7b22a305a998c040
[3] https://irclog.perlgeek.de/perl6/2017-02-23#i_14152769
