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.