Date: Tue, 17 Nov 1998 08:55:58 -0600
From: Eric Rudd <rudd AT cyberoptics DOT com>
Subject: Re: src/libc/ansi/stdlib/rand.c
To: djgpp-workers AT delorie DOT com
Message-id: <36518E7D.A4FAEAB9@cyberoptics.com>
Organization: CyberOptics
MIME-version: 1.0
X-Mailer: Mozilla 4.05 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: <8da1240a DOT 3650a594 AT aol DOT com>
Reply-To: djgpp-workers AT delorie DOT com

Kbwms AT aol DOT com wrote:

> Dear Martin Str|mberg,
>
> On 11-16-98 at 16:01:45 EST you wrote:
> > First my opinion: stick with the standard.
> >
> > Second my (potential) improvement: you say the seed is only 32 bits
> > and the state is 64. How about using seed&(((long long)seed)<<32) or
> > some other interesting combination to get a 64 bit seed? I do not know
> > the effect on the pseudo-randomness this has. Perhaps K. B. can
> > advice?
>
> With an linear congruential random number generator, all seeds are equal.
> That includes 0.
>
> K.B. Williams

If the linear congruential random number generator produces all possible
seeds before repeating, I would agree.  On the other hand, if the seed is
outside the "orbit", a generator can get stuck.  Here is a simple example:

   x[i+1] = (a*x[i]) % b + c

If c = 0, this generator gets stuck at 0.  Of course, one can choose a and c
such that all integers in the range [0, b> are generated exactly once before
the generator repeats, which takes care of that problem.

However, there is another problem with a 64-bit generator and a 32-bit seed,
in that it will not be possible to re-start the generator at some state that
it has gotten itself into.  For instance, if one has called the generator a
few times, seen some interesting behavior that one wishes to investigate (a
bug, perhaps?), one may wish to re-start the generator at that point.  This
would not be possible if the range of the generator exceeds the range of the
seed.  My vote would be for a simple 32-bit generator.

-Eric Rudd
rudd AT cyberoptics DOT com