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: 28.5.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 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::X is invoked with
an X::result_typevalue s of arithmetic type (3.9.1), ...