Timothy J Miller <tmiller <at> mitre.org> writes:
(2 raisedTo: 128) atRandom hex
Gives me results like:
B990880B732110000000000000000001 BFD3A7B37FA750000000000000000001 E0A6F981C14DF0000000000000000001
Somehow I'm not buying the lower-order bits on this one. :)
Yes, bad!
I recommand you use the 'debug it' menu in the workspace and execute step by step in the debugger to understand what goes on...
The key is Random>>#nextInt: anInteger ^ (self next * anInteger) truncated + 1
Random>>#next uses Floating point arithmetic. Thus you get the 53 bits precision of a Float mantissa (IEEE 754 double). It then gets shifted (128-53) times. There's probably a trick that rounds Float last bit to zero (like round to nearest integer always occur). And you might be able to understand the trailing 1.
Worse, the default Random generator does a modulo (2 raisdeTo: 31) - 1. That is, it can generate at most (2 raisdeTo: 31) different numbers... That happens to be the number of SmallInteger in the system, so it probably works better for SmallIntegers. A different strategy should be adopted for LargePositiveInteger>>atRandom... Let us say current implementation is very limited...
I suggest you open a mantis account and report the issue at http://bugs.squeak.org
Nicolas