CODEWITHSUNDEEP
c++c++11random
Lightness Races in Orbit
Lightness Races in Orbit

Reputation: 385144

Why does the mersenne_twister_engine guarantee certain results?

I note the following on cppreference's article for std::mersenne_twister_engine (e.g. std::mt19937):

The 10000th consecutive invocation of a default-constructed std::mt19937 is required to produce the value 4123659995.

The 10000th consecutive invocation of a default-constructed std::mt19937_64 is required to produce the value 9981545732273789042.

Assuming that this interpretation of the standard is accurate, what's the deal? Why do these guarantees exist? Isn't this non-random?

Upvotes: 2

Views: 370

Answers (2)

Ralf Ulrich
Ralf Ulrich

Reputation: 1714

All technical useful random number generators are pseudo-random generators (wikipedia) by design. This means they have a seed, and produce 100% identical sequences based on a given seed. This is a critical requirement for application in Monte Carlo simulations, etc., where you can run into rare problems or bugs, and without this feature it would be impossible to develop any stable complex Monte Carlo simulation sequence.

So random numbers do NOT produce random numbers. They produce sequences of numbers that have zero correlation over any or very long distance.

In your example, default initialization just correspond to one particular of such sequences.

Upvotes: 3

Lightness Races in Orbit
Lightness Races in Orbit

Reputation: 385144

From the proposal, N1398:

How can a user have confidence that the implementation of a random-number engine is exactly as specified, correctly taking into account any platform pecularities [sic] (e.g., odd-sized ints)? After all, minor typos in the implementation might not be apparent; the numbers produced may look "random". This proposal therefore specifies for each engine the 10000th number in the random number sequence that a default-constructed engine object produces.

So it's just a relatively arbitrary "waypoint", chosen as a way to ensure compliance of the implementation to the semantics of this PRNG.

It's not a semantic constraint per se; it's a verification that the implementation abides by the requirements.

IMO a note in the standard text might be in order, seeing as this is an unprecedented way to double-check quality of implementation. (I'm not aware of any other feature whose implementation's QoI may be verified by sample data given in the standard text itself.)

Credit is due to Blastfurnace for first arriving at this notion.

Upvotes: 5

Related Questions