On Mon, Nov 22, 2021 at 12:51 PM Matthew Woehlke via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On 19/11/2021 13.20, Arthur O'Dwyer via Std-Proposals wrote:
> > On Fri, Nov 19, 2021 at 1:09 PM Jason McKesson via Std-Proposals wrote:
> >> Or we could split the difference by allowing the user to provide an
> >> integer number for the maximum number of values to extract from
> >> `random_device`. Maybe even make providing the integer mandatory.
> >
> > The operation of "specifying a number of bits to take from random_device,
> > and then 'key-stretching' those into a larger seed value suitable for
> > MT19937," sounds like a perfect job for... a PRNG. ;)
> >
> > // Consume a lot of randomness from the OS to seed mt19937
> > auto g = nonstd::mt19937(std::random_device{});
> >
> > // Consume only 256 bits of randomness from the OS to seed xoshiro256ss;
> > // then consume a lot of *pseudo*-randomness from xoshiro256ss to seed
> > mt19937
> > auto g = nonstd::mt19937(nonstd::xoshiro256ss(std::random_device{}));
>
> ...which is superior to feeding MT 256 bits of initial entropy *how*
> exactly? You will still have a maximum of 2^256 possible sequences
> (albeit different ones from if you used those 256 bits directly). If
> this results in *higher quality* sequences from MT, that seems like an
> implementation issue with MT.

The general idea is that seed_seq is a bad API for doing the job of
under-seeding an RNG. If you have X random bits and you want to seed
an RNG that has Y bits of seed, where X < Y, it would be better to
seed an RNG that takes X bits and then use random numbers generated
from that to seed the Y-bit RNG.

The main difference between the two is that `seed_seq` heap-allocates
storage for the seed sequence, while the RNG-taking-X-bits will only
be stack-allocated. The only reason the RNG engine based method
doesn't work currently is that RNG engines don't provide the
SeedSequence interface. Not because they *can't*, but simply because
they're not specified to.