On Fri, 26 Aug 2016 22:31:11 -0700, cookbook_...@yahoo.co.jp wrote: > See the following result > > $ perl6 -e '(1..^(1+10e-15)).rand.say' > 1.00000000000001 > > $ perl6 -e 'say 1.00000000000001 - (1+10e-15)' > 0 > > $ perl6 -e '(1..^(1+10e-15)).excludes-max.say' > True > > I think that the 1st example it shouldn't return 1+10e-15, since > Range.excludes-max is True. > > My Perl 6 version is > $ perl6 --version > This is Rakudo version 2016.07.1-199-gdd9b760 built on MoarVM version > 2016.07-17-g40948f6 > implementing Perl 6.c.
Thank you for the report. This is now fixed (to clarify, what's fixed is the .rand occasionally producing a value equal to the excluded end point, so the one-liner lizmat produced no longer exits. When the generated numbers are printed, they still show only the "1.00000000000001" and "1", despite actual values being noisier). Fix https://github.com/rakudo/rakudo/commit/334d1344a3ce42ee3a81105f97bedd4943eb7c77 Test: https://github.com/perl6/roast/commit/55febd621da788772ed1fed1ed67dbb23a8409dc I'm also reproducing the fix commit message since it answers some of the questions asked on the ticket: Fix Range.rand generating value equal to excluded endpoints Fixes RT#129104: https://rt.perl.org/Ticket/Display.html?id=129104 The discussion in the ticket speculates this only affects Num ranges, however from the code I see other types are affected as well. For example using a Rat 1.00000000000001 has the same issue in lizmat's one liner. Reproducing with an Int is a bit harder due to much larger pool of possible random numbers, but sometime... somewhere... in a nuclear plant running on Perl 6, a .rand on Int range with endpoint exclusions will produce a value equal to the excluded endpoint. The problem is due to us checking generated value against zero and $!min-$!max, fix by adding the $!min before doing exclusion point equality checks. This way, the floating point noise does not introduce a difference between what we checked against and what we return. I measured performance impact of this on 100,000 iterations and found it to be only 1.1% speed loss.
