bruce@godot.UUCP (Bruce Nemnich) (06/14/84)
In the 4.2bsd franz (I don't know about others), (random) has the
extremely non-random property of alternating even and odd numbers.
To repeat, (loop for i from 1 to 20. collecting (random 2)).
I am not an expert on random-number algorithms, so if anyone has a good
fix, please let me know.
--
--Bruce Nemnich, Thinking Machines Corporation, Waltham, MA
{decvax!cca,ihnp4!mit-eddie,allegra!ias}!godot!bruce, BJN@MIT-MC.ARPAbruce@godot.UUCP (Bruce Nemnich) (06/14/84)
I just looked at the source, and (random) just calls rand(3) internally.
It is rand() which is alternating even and odd values. random(3) doesn't
seem to have this problem, so I changed the call in
/usr/src/ucb/lisp/franz/lam8.c to random().
--
--Bruce Nemnich, Thinking Machines Corporation, Waltham, MA
{decvax!cca,ihnp4!mit-eddie,allegra!ias}!godot!bruce, BJN@MIT-MC.ARPAags@pucc-i (Seaman) (06/14/84)
> In the 4.2bsd franz (I don't know about others), (random) has the > extremely non-random property of alternating even and odd numbers. Knuth (Vol. 2, Seminumerical Algorithms) makes the following observations about random number generators of the linear congruential type: (m = modulus, w = word size) 1. Using m = w has an enormous advantage in speed, since it avoids the need for a divide. 2. When m = w, the right-hand digits of the generated numbers are much less random than the left-hand digits (this explains the even-odd behavior). 3. A reasonable alternative is to use m = (w plus or minus 1), which makes the right-hand digits more random at the cost of time. 4. "In most applications, the low-order bits are insignificant, and the choice m=w is quite satisfactory -- provided that the programmer using the random numbers does so wisely." (this a direct quote) The man entry for rand(3) points out that random(3) should be used in new applications and that rand remains for compatibility. -- Dave Seaman "My hovercraft is full of eels." ..!pur-ee!pucc-i:ags