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.

### 729. Problem in [rand.req.eng]/3

Section: 26.6.3.4 [rand.req.eng] Status: NAD Submitter: Stephan Tolksdorf Opened: 2007-09-21 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [rand.req.eng].

View all issues with NAD status.

Discussion:

The 3rd table row in 26.6.3.4 [rand.req.eng]/3 requires random number engines to accept any arithmetic type as a seed, which is then casted to the engine's `result_type` and subsequently used for seeding the state of the engine. The requirement stated as "Creates an engine with initial state determined by `static_cast<X::result_type>(s)`" forces random number engines to either use a seeding method that completely depends on the `result_type` (see the discussion of seeding for the `mersenne_twister_engine` in point T2 above) or at least to throw away "bits of randomness" in the seed value if the `result_type` is smaller than the seed type. This seems to be inappropriate for many modern random number generators, in particular F2-linear or cryptographic ones, which operate on an internal bit array that in principle is independent of the type of numbers returned.

Possible resolution: I propose to change the wording to a version similar to "Creates an engine with initial state determined by `static_cast<UintType>(s)`, where `UintType` is an implementation specific unsigned integer type."

Additionally, the definition of s in 26.6.3.4 [rand.req.eng]/1 c) could be restricted to unsigned integer types.

Similarly, the type of the seed in 26.6.3.5 [rand.req.adapt]/3 e) could be left unspecified.

See N2424 for further discussion.

[ Stephan Tolksdorf adds pre-Bellevue: ]

> In reply to the discussion in N2424 regarding this issue:

> The descriptions of all engines and engine adaptors given in sections 26.6.4 [rand.eng] and 26.6.5 [rand.adapt] already specify the concrete types of the integer arguments for seeding. Hence, relaxing the general requirement in 26.6.3.4 [rand.req.eng] would not affect portability and reproducibility of the standard library. Furthermore, it is not clear to me what exactly the guarantee "with initial state determined by `static_cast<X::result_type>(s)`" is useful for. On the other hand, relaxing the requirement would allow developers to implement other random number engines that do not have to cast all arithmetic seed arguments to their result_types.

[ Bellevue: ]

> Propose close NAD for the reasons given in N2424.

Proposed resolution:

See N2424 for further discussion.

[ Stephan Tolksdorf adds pre-Bellevue: ]

> Change row 3 of table 105 "Random number engine requirements" in 26.6.3.4 [rand.req.eng]/3

> > Creates an engine with initial state determined by `static_cast<X::result_type>(s)`

> Similarly, change 26.6.3.5 [rand.req.adapt]/3 e)

> > When `X::X` is invoked with an `X::result_type` value `s` of arithmetic type (3.9.1), ...