>Juan Cires Martinez wrote:
>Most random number generators perform their internal computations on
>integers only.  Squeak's RNG algorithm certainly appears to be based
>on such a system... so can anyone explain why the calculations are all
>being done in floating point?  I would expect this to cause trouble
>with roundoff.  (The integer-based origins of the algorithm can be
>glimpsed at least in the seed initialization, Random>>seed: anInteger.
>So what's going on here, exactly?)
>
>It seems to me the correct solution is to take out all the asFloat
>stuff, and apply it instead to the return value of Random>>next.  That
>way, all calculations are performed internally with integers, which
>shouldn't cause the problem described above, and would be more
>amenable to producing various random integer distributions.

Indeed, this random number generator is based on a veru well-known
32-bit integer random number generator. However, since Squeak's
integers have two fewer bits than an unsigned C ints (one for the
"integer" bit, one for the sign bit), the first version of this
32-bit generator frequently overflowed into LargePositiveIntegers.
It got the right answer, but it was quite slow. Thus, someone
(either David N. Smith or Dan Ingalls, I think) re-wrote it using
Squeak's Floats, which are 64 bit double precision Floats with
more than enough bits of mantissa. This was much faster, since
all the arithmetic used the float primitives.

That's the history.

I wonder if this problem of getting stuck in a cycle is a side
effect of floating point roundoff and/or normalization? I would
expect the integer version of the algorithm to be free of this
problem; it was a well-tested and studied choice of parameters,
which is  why we chose it.

	-- John