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