Implementation of make-random-real-generator Bradley Lucier (05 May 2020 01:07 UTC)
Re: Implementation of make-random-real-generator John Cowan (05 May 2020 03:02 UTC)
Re: Implementation of make-random-real-generator Lucier, Bradley J (05 May 2020 03:30 UTC)
Re: Implementation of make-random-real-generator John Cowan (05 May 2020 04:11 UTC)
Re: Implementation of make-random-real-generator Arvydas Silanskas (05 May 2020 18:49 UTC)
Re: Implementation of make-random-real-generator Marc Nieper-Wißkirchen (05 May 2020 19:00 UTC)
Re: Implementation of make-random-real-generator Bradley Lucier (05 May 2020 19:08 UTC)
Re: Implementation of make-random-real-generator John Cowan (05 May 2020 20:25 UTC)
Re: Implementation of make-random-real-generator Lucier, Bradley J (05 May 2020 20:27 UTC)
Re: Implementation of make-random-real-generator Shiro Kawai (05 May 2020 20:32 UTC)
Re: Implementation of make-random-real-generator Marc Nieper-Wißkirchen (05 May 2020 20:38 UTC)
Re: Implementation of make-random-real-generator Shiro Kawai (05 May 2020 20:55 UTC)
Re: Implementation of make-random-real-generator Bradley Lucier (05 May 2020 20:58 UTC)
Re: Implementation of make-random-real-generator John Cowan (05 May 2020 21:01 UTC)
Re: Implementation of make-random-real-generator Marc Nieper-Wißkirchen (05 May 2020 21:07 UTC)
Re: Implementation of make-random-real-generator Shiro Kawai (05 May 2020 21:01 UTC)
Re: Implementation of make-random-real-generator Bradley Lucier (05 May 2020 20:57 UTC)

Re: Implementation of make-random-real-generator Marc Nieper-Wißkirchen 05 May 2020 20:38 UTC

Am Di., 5. Mai 2020 um 22:32 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> Hmm, I don't quite remember why I included the boundary when I wrote Gauche data.random.   Looking at the original code and comment, I think I omitted code to reject boundary values, since the caller can always exclude them if he wants, but the reverse is not trivial.   (Even the source random generator doesn't include boundaries, range conversion could result to produce them by rounding, so rejection code must be there based on the final value, I think.)
>
> Now I think, in practice, it is better to be aligned with srfi-27 (open boundary).

I would agree. But even with SRFI 27, the boundary could be delivered
as a result. The point is that the real numbers delivered are inexact
and, accordingly, the R7RS specifies that comparing inexact numbers is
unreliable. In other words, the consumer of the random values cannot
determine whether the actual boundary was delivered or not.

With this in mind, I am wondering about the justification of SRFI 27.
Depending on the representation of inexact floats, (log x) can result
in a non-finite result even if (> x 0) is #t.