Is there such a thing as a "good/bad" seed in pseudo-random number generation?

Question

Well, I don't really have much to add to the title. I tend not to use seeds in preudo-random number generation, but they are handy when an initial research project that includes simulations expands to include more aspects of the same simulation study.

In that case, if a seed was used, one can perform only the additional tasks.

So are there any "good practice" tips for choosing seeds, or they can be chosen... at random?

Answer 1

You might want to look at Matsumoto et al.'s "Common Defects in Initialization of Pseudorandom Number Generators".

In one sense shouldn't matter what seed you use, in that with a good PRNG, weird results should be rare, just as low-probability outcomes in nature should be rare. Whether you can use the same seed all of the time, as some people do, depends on the application. I personally would never do this, but I run Monte Carl simulations in which different seeds might produce different patterns of outcomes, and I want to know whether this happens. The data that I ultimately care about is is the collection of data I get when I run the simulation many times with the same parameters but different seeds. I can then perform statistics on this data, plot summary data, etc.

Mersenne Twister and other algorithms:

Concerning jbowman's comment, not everyone is as negative about Mersenne Twisters as O'Neill (pcg-random.org/other-rngs.html). If you don't care about M.T.'s extremely long period (arguably overkill), there are better algorithms (including, I think, O'Neill's PCG algorithms, though there's been some debate between O'Neill and Vigna about whose algorithms are better). However, M.T. is still common in software packages that I trust, where PRNG quality matters. (By contrast, some Java rand() functions are not as good.)

Any decent implementation of Mersenne Twister will initialize its state with another, simpler PRNG, which might differ for different implementations (cf. these remarks by Matsumoto). The Twister should then be iterated at least 624 times (better yet, twice that number) before using its output. If you do that, you shouldn't have a problem with nearby seeds. (A high-quality agent-based modeling library, MASON uses Mersenne Twister with this scheme, and if you tell it to perform multiple runs with the same parameters, by default it will simply increment the first seed for each subsequent run.)

Another issue with Mersenne Twisters is that if its internal 624x32-bit state has many zero bits, it takes many iterations to get out of that pattern. (See Pannetton et al. "Improved Long-Period Generators Based on Linear Recurrences Modulo 2", which describes a better algorithm, WELL, although with shorter periods.) However, if you initialize the Mersenne Twister in the usual way with another pseudorandom number generating algorithm, I would think that the zeros issue would be unlikely to be a serious problem, since it should be rare that such an algorithm gives a Mersenne Twister a starting state with a lot of zero bits. (The most recent version of M.T. has less of a problem with zero bits; see Saito and Matsumoto, "SIMD-oriented Fast Mersenne Twister: a 128-bit Pseudorandom Number Generator", pages 13-14.)

(N.B. Extra details on Mersenne Twisters: The remarks above are for the most common kind of Mersenne Twister with a 624x32-bit internal state and a period of $2^{19937}−1$. If you seed it directly, you need to provide 624 32-bit numbers as a seed. Since it's usually undesirable to have to do that, by default you give a wrapper function a 32-bit (or possibly 64-bit) seed, which passes it to a simpler, lower-quality pseudorandom number generator. This is used to generate the 624x32-bit seed for the Mersenne Twister. However, the way that a M.T. works is that it takes successive numbers from its state, passes them to a function that rearranges the bits in the number, and outputs the result. When all 624 numbers are used this way, it performs an operation on the entire internal state (including a step known as a "twist") to generate a new 624x32-bit state. This is why you should not use the first 624 or 1248 outputs; they are partially the result of a lower-quality pseudorandom number generator, and are not due to the full Mersenne Twister algorithm. Kneusel's introductory book on PRNGs includes an introduction to Mersenne Twisters, but read the xorshift section first.)

(Other introductory texts--not quite as easy as Kneusel, and they don't necessarily cover Mersenne Twisters, if that's what you're interested in--include:

• Johnston's Random Number Generators--Principles and Practices.
• Knuth, Chapter 3 in volume 2 of the 3rd edition of The Art of Computer Programming (still deserves to be called the "bible" of PRNGs, even though there have been crucial innovations since it was published).
• Several papers at Pierre L'Ecuyer's site
• The paper by O'Neill mentioned above.)