Proposed resolution:

In [rand.eng.mers]:

Insert at the end of para 2.:

[Note: The lower r bits of X_i-n do not influence the state transition and hence should not be compared when comparing two mersenne_twister_engine objects. -- end note]

In para 5. change:

The textual representation of x_i consists of the values of X_i-n bitand ((2^w - 1) - (2^r - 1)), X_i-(n-1), ..., X_i-1, in that order.

[ Bellevue: ]

Fermi Lab has no objection to the proposed change. However it feels that more time is needed to check the details, which would suggest a change to REVIEW.

Bill feels that this is NAD, not enough practical importance to abandon the simple definition of equality, and someone would have to do a lot more study to ensure that all cases are covered for a very small payback. The submitter admits that "These changes would likely have no practical effect,", and according to Plum's razor this means that it is not worth the effort!

Revisted: Agree that the fact that there is no practical difference means that no change can be justified.

[tr.rand.eng.mers](10) requires that operator== for the mersenne_twister returns true if and only if the states of two mersenne_twisters, consisting each of n integers between 0 and 2^w - 1, are completely equal. This is a contradiction with [tr.rand.req](3) because the given definition of the state also includes the lower r bits of x(i-n), which will never be used to generate a random number. If two mersenne_twisters only differ in the lower bits of x(i-n) they will not compare equal, although they will produce an identical sequence of random numbers.

[rand.eng.mers] in the latest C++ draft does not specify the behaviour of operator== but uses a similar definition of the state and, just like [tr.rand.eng.mers], requires the textual representation of a mersenne_twister_engine to consist of X_i-n to X_i-1, including the lower bits of X_i-n. This leads to two problems: First, the unsuspecting implementer is likely to erroneously compare the lower r bits of X_i-n in operator==. Second, if only the lower r bits differ, two mersenne_twister_engines will compare equal (if correctly implemented) but have different textual representations, which conceptually is a bit ugly.

I propose that a paragraph or footnote is added to [rand.eng.mers] which clarifies that the lower r bits of X_i-n are not to be compared in operator== and operator!=. It would only be consequent if furthermore the specification for the textual respresentation was changed to X_i-n bitand ((2^w - 1) - (2^r - 1)), X_i-(n-1), ..., X_i-1 or something similar.

These changes would likely have no practical effect, but would allow an implementation that does the right thing to be standard-conformant.