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.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 29.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 29.5.3.4 [rand.req.eng]/1 c) could be restricted to unsigned integer types.
Similarly, the type of the seed in 29.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 29.5.4 [rand.eng] and 29.5.5 [rand.adapt] already specify the concrete types of the integer arguments for seeding. Hence, relaxing the general requirement in 29.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 29.5.3.4 [rand.req.eng]/3
Creates an engine with initial state determined by
static_cast<X::result_type>(s)Similarly, change 29.5.3.5 [rand.req.adapt]/3 e)
When
X::Xis invoked withanvalueX::result_typesof arithmetic type (3.9.1), ...