2.16.5 Design rationale

Why not combine random-integer and random-real?

The two procedures are not combined into a single variable–arity procedures 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 not some object–oriented interface?

There are many alternatives to the interface as specified in this SRFI. In particular, every framework for object–orientation can be used to define a class for random sources and specify the interface for the methods on random sources. However, as the object–oriented frameworks differ considerably in terms of syntax and functionality, this SRFI does not make use of any particular framework.

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, is 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:

• 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.
• 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 application can be used.
• Generate real numbers: Unlike the choose–from–set case, the range and the quantization is constant over a potentially very large number of calls. In addition, there are usually just a few distinct instances of quantization and number type, most likely corresponding to underlying float and double representations. Therefore, random-real does not accept any parameters but the procedure random-source-make-reals creates a properly configured random-real procedure.

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 arithmetics 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.