python - Impact of setting random.seed() to recreate a simulated behaviour and choosing the seed

Question

I am doing a scheduling simulation in python which is full determinstic. So, when I have the same input and parameters I always get the same output.

Now I want to randomize the initial starting state of the simulation and compare the output of two (or more) different simulation parameters. To compare the "same randomized initial starting state" I want to set the random.seed() with an initial value, which should stay the same for all comparisions of different schedulers. Furthermore I want to see the behaviour for one scheduler on different initial states so I have to change the random.seed(). This I have to do of course for all schedulers.

Now my question is, what impact has the seed on the "randomness" of the random generator? For example does it matter if I choose as a seed 1 or 100? And because I want to use different seeds for the same scheduler and compare it to the other ones, can I simply use e.g. the seeds 1 to 10 or must my seeds be "more random"?

For clarification, I use the random generator for distributing tasks initial on different cores and compare the output to "my optimal (deterministic) initial distribution". I want to get a wide-spread of different distributions with my choosen seeds.

Answer 1

Although your choice of seed doesn't matter in theory, it may matter in practice.

1. There are many PRNGs for which a given seeding strategy will produce correlated pseudorandom number sequences. For example, in most versions of PCG, two sequences generated from seeds that differ only in their high bits will be highly correlated ("Subsequences from the same generator"). Another example, this time involving Unity's PRNG, is found in "A Primer on Repeatable Random Numbers".
2. If you choose sequential seeds, or seeds that differ only very slightly, it may matter how the seed is used to initialize the PRNG's state. I don't know how well base Python's random.seed(integer_seed) avoids this problem, but if two Mersenne Twister states differ in only one bit, the two sequences they produce will be correlated to each other, and it will take millions of numbers to eliminate this correlation. A similar issue occurs with many other PRNGs, especially linear PRNGs.
3. Mersenne Twister has a huge state (about 20,000 bits) compared to other PRNGs in common use (which are typically 32 to 128 bits). Unless you seed a PRNG with a seed as big as its state, there will be some PRNG states that will never be produced (and therefore some pseudorandom number sequences that will never be generated). See also this question, which discusses seeding Mersenne Twister, which is the algorithm used in base Python.

To reduce the risk of correlated pseudorandom numbers, you can use PRNG algorithms, such as SFC and other so-called "counter-based" PRNGs (Salmon et al., "Parallel Random Numbers: As Easy as 1, 2, 3", 2011), that support independent "streams" of pseudorandom numbers. (Note, however, that PCG has a flawed notion of "streams".) There are other strategies as well, and I explain more about this in "Seeding Multiple Processes". See also this question.

Also, if you're using NumPy (which is a popular Python library for scientific work), note that NumPy 1.17 introduces a new pseudorandom number generation system; it uses so-called bit generators, such as PCG, and random generators, such as the new numpy.random.Generator. It was the result of a proposal to change the PRNG policy. The NumPy documentation has detailed information on seeding PRNGs in parallel.