*This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.*

**Section:** 29.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

**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`

, are completely
equal. This is a contradiction with 99 [tr.rand.req](3) because the given
definition of the state also includes the lower ^{w} - 1`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.

29.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`

to _{i-n}`X`

, including the
lower bits of _{i-1}`X`

. This leads to two problems: First, the
unsuspecting implementer is likely to erroneously compare the lower _{i-n}`r`

bits of `X`

in _{i-n}`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 29.5.4.3 [rand.eng.mers] which
clarifies that the lower `r`

bits of `X`

are not to be compared in
_{i-n}`operator==`

and `operator!=`

. It would only be consequent if furthermore
the specification for the textual respresentation was changed to
`X`

or
something similar.
_{i-n} bitand ((2^{w} - 1) - (2^{r} - 1)), X_{i-(n-1)}, ..., X_{i-1}

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 29.5.4.3 [rand.eng.mers]:

Insert at the end of para 2.:

[

Note:The lower`r`

bits of`X`

do not influence the state transition and hence should not be compared when comparing two_{i-n}`mersenne_twister_engine`

objects.-- end note]In para 5. change:

The textual representation of

`x`

consists of the values of_{i}`X`

, in that order._{i-n}bitand ((2^{w}- 1) - (2^{r}- 1)), X_{i-(n-1)}, ..., X_{i-1}