### 799. Mersenne twister equality overspecified

**Section:** 28.5.4.3 [rand.eng.mers], 99 [tr.rand.eng.mers] **Status:** NAD
**Submitter:** Stephan Tolksdorf **Opened:** 2008-02-18 **Last modified:** 2023-05-24 13:57:23 UTC

**Priority: **Not Prioritized

**View all other** issues in [rand.eng.mers].

**View all issues with** NAD status.

**Discussion:**

99 [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 99 [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_twister`s
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.

28.5.4.3 [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
99 [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_engine`s 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 28.5.4.3 [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.

*[
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.

**Proposed resolution:**

In 28.5.4.3 [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.