Re: draft random-number-generator API

[Zack Weinberg <zack@rabi.phys.columbia.edu>]

On 03 Sep 1998 17:51:59 -0700, Ulrich Drepper wrote:
>Zack Weinberg <zack@rabi.phys.columbia.edu> writes:
>
>> Comments?  (Obviously this isn't for 2.1, I'll do it up as an add-on
>> initially)
>
>Two comments for now:
>
>- rand_r: the interface of this function is so braindamaged that it cannot
>  be improved very much and I don't know whether it fits into your framework.
>  The problem is that the value the argument poitns to (a 32bit value) must
>  contain the complete state of the RNG.
>
>- *rand48: Here we are bound by the standard to use exactly the algorithm
>  currently implemented.  I.e., you cannot use a different engine as long
>  as you cannot emulate that algorithm.

I solve both these in the same way:  if you use an interface that forces one
algorithm, then that algorithm gets used.  If you call rand_r, you always
get the POSIX algorithm.  If you call [enj]rand48, you always get the SVID
algorithm.  But if you call [dlm]rand48, you get the global default
algorithm, which might or might not be SVID.  (If you've called lcong48, it
is.)

This does technically violate the standard, but consider that rand() is
specified by POSIX and already we use a different (better) algorithm.

Incidentally, these are the algorithms I was planning to provide initially:

RNG_POSIX	/* POSIX specified algorithm - don't use */
RNG_BSD		/* BSD trinomial generator with variable state size */
RNG_SVID	/* SVID 48-bit linear congruential generator */

RNG_LCONG32	/* Tunable LCRNG mod 2^32 */
RNG_LCONG48	/* mod 2^48 */
RNG_LCONG64	/* mod 2^64 */

RNG_KNUTH	/* Knuth's subtractive algorithm */
RNG_H800	/* H800 generator */
RNG_MTWIST	/* Mersenne Twister */
RNG_SHA		/* Secure Hash Algorithm */

with the global default probably being H800 (which is faster and better than
BSD with 128 words of state, and uses roughly the same amount of memory).

RNG_POSIX and RNG_SVID are special cases of RNG_LCONG32 and RNG_LCONG48
respectively.

zw