Trivial Randomness
I believe that WG1 Scheme should provide just a little randomness. Student programs often want a source of random reals or integers, and don't want to have to implement it themselves. Implementations may be able to provide truly random data, or may provide a high-quality PRNG.
Procedures
These two procedures have the same syntax and semantics as their SRFI 27 counterparts.
(random-integer n) -> x
The next integer x in {0, ..., n - 1} obtained from a source of random bits. Subsequent results of this procedure appear to be independent and uniformly distributed over the range {0, ..., n - 1}. The argument n must be a positive integer.
(random-real) -> x
The next number 0 < x < 1 obtained from a source of random bits. Subsequent results of this procedure appear to be independent and uniformly distributed. The numerical type of the results and the quantization of the output range depend on the implementation.
Design Rationale (from SRFI 27)
- Why not combine random-integer and random-real?
- We avoid combining the two procedures into a single variable-arity procedure in order to save a little time and space during execution. Although some Scheme systems can deal with variable arity as efficiently as with fixed arity, this is not always the case, and time efficiency is very important here.
- Why is there not just a generator with a fixed range?
- A bare fixed-range generator is of very limited use. Nearly every application has to add some functionality to make use of the random numbers. The most fundamental task in manipulating random numbers is to change the range and quantization. This is exactly what is provided by random-integer and random-real. In addition, it saves the user from the pitfall of changing the range with a simple modulo computation, which may substantially reduce the quality of the numbers being produced.
The design of the interface is based on three prototype applications:
1. Repeatedly choose from relatively small sets: As the size of the set is likely to vary from call to call, random-integer accepts a range argument n in every call. The implementation should try to avoid boxing/unboxing of values if the ranges fit into immediate integers.
2. Generate a few large integers with a fixed number of bits: As generating the random number itself is expensive, passing the range argument in every call does not hurt performance. Hence, the same interface as in the first case can be used.
3. Generate real numbers: Unlike the first case, the range and the quantization are constant over a potentially very large number of calls. In addition, there is usually only one distinct instance of quantization and number type, most likely corresponding to the underlying C double representation. (A few Schemes implement more than one kind of inexact number.) Therefore, random-real does not accept any parameters.
- Why bother about floating-point numbers at all?
A proper floating-point implementation of a random number generator is potentially much more efficient that an integer implementation because it can use more powerful arithmetic hardware. If in addition the application needs floating-point random numbers, it would be an intolerable waste to run an integer generator to produce floating point random numbers. A secondary reason is to save the user from the 'not as easy as it seems' task of converting an integer generator into a real generator.
- Why are zero and one excluded from random-real?
- The procedure random-real does not return x = 0 or x = 1 in order to allow (log x) and (log (- 1 x)) without the danger of a numerical exception.