On Fri, Aug 22, 2008 at 7:34 AM, Andreas Raab <
[hidden email]> wrote:
> Today I've encountered two very interesting issues with respect to Random.
> First, there seems to be a bug when using very large seeds, for example:
>
> rnd := Random seed: 300000000000.
> rnd nextInt: 100.
>
> This answers -121 which is just plain completely wrong! Any ideas for how to
> fix this?
It's to be expected given the initialization parameters for the
algorithm so maybe it should throw an exception when it gets a seed
out of range. I'd just use a 32 bit integer as a seed unless I really
wanted to tinker with PRNGs (and I don't given the quirkiness of those
things). Maybe the encryption package(s?) have an alternate one that
you could use if you really need big seeds that you can't reduce.
> Secondly, what is a good way to seed a random number generator that one will
> only pull out very few numbers? We found that a naive approach works very
> badly which is illustrated here:
>
> 1 to: 100 do:[:i|
> rnd := Random new.
> Transcript show: (rnd nextInt: 100); space.
> ].
>
> There is almost no variation in the numbers. If this would be running out of
> one image, I would do something like here:
>
> base := Random new.
> 1 to: 100 do:[:i|
> rnd := Random seed: (base nextInt: 1234567).
> Transcript show: (rnd nextInt: 100); space.
> ].
>
> which looks much more nicely distributed but unfortunately this code will be
> run in different images. So having something that is based on the millsecond
> clock is probably good but there still seems to be very little variation
> when I run a couple of tests.
But why do you need to keep getting new seeds? Random has this as the
initial default seed:
seed := (Time millisecondClockValue bitAnd: 16r3FFFFFFF) bitXor: self hash.
so I guess that if you are having issues with multiple machines
accidentally stumbling onto the same random sequence, you could xor
that again with the hash of the hostname and/or the process id of the
image in the system or the process id in the image.
--
Ragnar
Locked
