**Section:** 28.5.3.4 [rand.req.eng] **Status:** NAD
**Submitter:** Stephan Tolksdorf **Opened:** 2007-09-21 **Last modified:** 2016-01-28 10:19:27 UTC

**Priority: **Not Prioritized

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

**View all issues with** NAD status.

**Discussion:**

The 3rd table row in 28.5.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 28.5.3.4 [rand.req.eng]/1 c) could be restricted to unsigned integer types.

Similarly, the type of the seed in 28.5.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 28.5.4 [rand.eng] and 28.5.5 [rand.adapt] already specify the concrete types of the integer arguments for seeding. Hence, relaxing the general requirement in 28.5.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 28.5.3.4 [rand.req.eng]/3

Creates an engine with initial state determined by

~~static_cast<X::result_type>(~~s~~)~~Similarly, change 28.5.3.5 [rand.req.adapt]/3 e)

When

X::Xis invoked with~~an~~valueX::result_typesof arithmetic type (3.9.1), ...