Random Number Generator: Class level or Method level?

Question

Hi!

When using a Random Number Generator, which is the better way to use it for greater randomness of the new value:

1. Have a method that instantiates a new instance of the RNG each time and then returns a value?

2. Have an instance of the RNG at the class level, which is instantiated once in the Constructor, and all subsequent calls for a new random value using the existing instance?

The issue is that there may be many calls for a random number, often in different scopes not connected with each other.

This is not a performance issue, so the fact that each call might instantiate a new instance makes no difference. This is all about the randomness of the returned value.

Answer 1

Option 1 does not work, actually.

Option 2 is the only choice. RNG's absolutely require that you generate the values in sequence from a single seed.

Your "create a new generator with a new seed" breaks the mathematical foundation. What you get then totally depends on your seeds, which -- sadly -- won't be very random.

Answer 2

I suggest option 3: have a single RNG used throughout the program. It requires locking or a thread-local if the RNG isn't thread-safe (e.g. in .NET), but it makes life a lot simpler and you don't need to worry about repetition.

See the relevant MiscUtil page for details of the .NET StaticRandom class I wrote for this very purpose. (It's incredibly simple - nothing clever at all.)

Answer 3

Edit: I believe I mean option 3, as mentioned in another answer, i.e a global random manager, although within a specific class you can doe exactly the same thing.

Another advantage of using Option 2 is that if you ever require "replay" functionality in your software, you can simply store the seed which you used to initialise the RNG. Next time, you only need to force the RNG to use the stored seed and you will get the exact same set of behaviour, assuming that there are not other issues such as concurrency / threading which might change the order of execution.

You might want to do something like this if your software is running an experiment which requires a lot of randomness, but where you might wish to repeat a particular run to demonstrate to other people. It's also used a lot in computer games where the AI will take decisions based on weightings of possible choices, but with ultimately a random number "picking" what action they take.

It also makes debugging possible for transient bugs which only appear occasionally. If you don't store the seed of each run there is no way to recreate the exact conditions which caused the bug.