Integer >> #atRandom seems deterministic

[ValentinBourcier]

Bug description

Starting from a new image, the first executions of 10 atRandom are always returning 6, 3, 6, 2 ... in Pharo 9 and 7, 4, 6, 5, 4 ... in Pharo 11.
Results seem to be following a deterministic function.

To Reproduce

1. Start a new Pharo 11 image
2. Open a playground
3. Type 10 atRandom and print first results, ex: 1 to: 10 do: [ :i | 10 atRandom crTrace ]
4. Close the image by discarding any change
5. Restart the image and repeat steps 2 to 4.

Expected behavior

As its name states, this function should provide users with non-deterministic results.

Context

For an experiment, I am executing a program that initialize the image with random parameters.
Initialized images must be different from each others.

As a workaround I now use Random new next instead of atRandom.

Version information:

• OS: macOS Monterey (M1 Pro)
• Version: 12.2.1
• Pharo Version: 9 to 11

[svenvc]

I am not sure this is really a bug, it depends how you look at it.

Anyway, you already give a solution.

Another solution would be to access the shared random generator that is being used:

SharedRandom globalGenerator

You can send it initialize, useClockBasedSeed, useUnixRandomGeneratorSeed or just set a new seed of your own.

[noha]

I second what @svenvc said. Randomness cannot "just" be generated. An image is a stable artefact and so reopening gives the same result unless you give the initialize randomness to it. This can be from the OS are manually but hard to do automatic because the output would be detereministic again. This is usually called seeding. I tend to use

Random seed: Time microsecondClockValue

and keep the random object which seeds the Random in a way you can expect different values. Creating Random is slow so keeping one object is preferrable

[Gabriel-Darbord]

I would assume that a method named atRandom would return a random value, not one that I could predict.
If this is a feature, the most important outcome of this issue would be to raise awareness, such as adding documentation to SharedRandom and to the four methods that use it.
If this is a bug, then it could be fixed by resetting the seed of the generator in the methods, which is better than using a workaround imo.
Otherwise, it may (have already) lead to unexpected results in certain scenarios where randomness is critical.

[svenvc]

Maybe we could do the same as with UUIGenerator, namely add a class side startUp message to initialize and register with SessionManager in initializedSessionManager. That way a newly seeded SharedRandom globalGenerator will be available when the image comes up. This might be closer to user expectations.

[tesonep]

Yes, we need to startup the random generator everytime.

[svenvc]

I would change the class side of SharedRandom to:

globalGenerator
    ^ global ifNil: [ global := self new ]
reset
    global := nil
startUp
    self reset
initialize
    self reset.
    SessionManager default registerSystemClassNamed: #SharedRandom

By using startUp without the resuming parameter, the reset happens both when the image comes up and when the image is saved.

BTW, the default seeding of Random is clock based.

I am not sure if initializedSessionManager has to be changed or not, it seems unused.

[svenvc]

PR: #13022

[svenvc]

The PR has been integrated