From @titsuki

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.

From @titsuki

*1st example shouldn't

On 2016-8月-26 金 22​:31​:11, cookbook_000@​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.

From @lizmat

Welcome to the world of floating point accuracy.

This little program typically ends within 100 iterations for me​:

$ 6 'my int $a = 0; $a++ while (1..^(1+10e-15)).rand < 1+10e-15; say $a’
96

Either we dismiss this bug as being caused by lack of floating point accuracy, or we build in something special in .rand for Num Ranges that will make sure that the returned value actually is less then upper range as indicated by “<“.

I would mark this RT as a @​LARRY case.

On 27 Aug 2016, at 08​:31, Itsuki Toyota (via RT) <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Itsuki Toyota
# Please include the string​: [perl #​129104]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=129104 >

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.

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

From @zoffixznet

On Fri, 26 Aug 2016 22​:31​:11 -0700, cookbook_000@​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 rakudo/rakudo@334d134
Test​: Raku/roast@55febd6

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-archive.perl.org/perl6/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.

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