Bad value for Random seed ?

Hello,

  (Random seed: 16457315536128) nextInt: 11

gives -1853


Am I missing something ?

Stef

On 21 September 2014 14:04, Stéphane Rollandin <[hidden email]> wrote:
> Hello,
>
>  (Random seed: 16457315536128) nextInt: 11
>
> gives -1853
>
>
> Am I missing something ?

It looks like you're violating one of the (unwritten) assumptions of
the class. The class comment says "It is an adaptation of the
Park-Miller RNG which uses Floats to avoid the need for LargeInteger
arithmetic." Also, #nextValue says in its comment "This method
generates random instances of Integer in the interval 0 to
16r7FFFFFFF. " So with that in mind, we can see why you'd get a
negative number - integer overflow.

But having said that, I don't know if it's reasonable to assume that
the reader's dug into the guts of Random, especially when #nextint:
says "Answer a random integer in the interval [1, anInteger]." We
usually take pains to automatically convert between bignum and small
integers, and here we don't. What if you _do_ want a random number
that might be larger than 2^32?

frank

> Stef

On Sun, 21 Sep 2014, Stéphane Rollandin wrote:

> Hello,
>
> (Random seed: 16457315536128) nextInt: 11
>
> gives -1853
>
>
> Am I missing something ?

It's not documented, but this generator[1] is designed to work with 32 bit
integers. #nextValue generates 31 bit integers between 1 and 2147483647.
This actually breaks #next, which returns a value from (0..1] instead
of [0..1).

Based on the math in #nextValue seeds up to 96752654378 are safe, but
96752654379 will underflow. I suggest you to use 31 bit nonnegative
integers as seed.


Levente

[1] http://www.cems.uwe.ac.uk/~irjohnso/coursenotes/ufeen8-15-m/p1192-parkmiller.pdf

>
> Stef
>
>

Ok, thank you both.

Maybe we should put a guard to raise an error in case the seed is too
large ?

Stef

On Sun, 21 Sep 2014, Stéphane Rollandin wrote:

> Ok, thank you both.
>
> Maybe we should put a guard to raise an error in case the seed is too large ?

That's an easy, but not very user friendly solution. I think it would be
better to transform the input into a valid seed in a safe way. This means
creating a good hash function which maps any integer into 0..2^31-1.


Levente

>
> Stef
>
>

Actually it looks like using smallish values for seed is a problem too:

((1 to: 1000) collect: [:n | (Random seed: 1000 atRandom) nextInt: 10])
asSet

gives

a Set(1)


Stef

I should add that it is only the first integer that is always 1:

((1 to: 1000) collect: [:n | (Random seed: 1000 atRandom) nextInt: 10;
nextInt: 10]) asSet

gives

  a Set(1 2 3 4 5 6 7 8 9 10)


Stef

I've uploaded a new version to the Inbox. which should solve the problems
with Random. For this particular issue, you can use #hashSeed:

((1 to: 10000) collect: [:n | (Random basicNew hashSeed: n) nextInt: 10 ] as: Bag) sortedCounts.

gives

  {1007->10 . 1006->7 . 1004->1 . 1004->4 . 1004->8 . 1003->3 . 998->5 .
995->6 . 992->9 . 987->2}

while

((1 to: 10000) collect: [:n | (Random basicNew seed: n) nextInt: 10 ] as: Bag) sortedCounts.

still gives

  {10000->1}


Levente

On Sun, 21 Sep 2014, Stéphane Rollandin wrote:

IMO a lagged Fibonacci generator would be a better choice.  It offers
better quality output, and it's also faster.

On 9/21/14 8:18 , Stéphane Rollandin wrote:
> Ok, thank you both.
>
> Maybe we should put a guard to raise an error in case the seed is too
> large ?
>
> Stef
>
>