Date: Mon, 22 Nov 2021 12:50:45 -0500
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.
> 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.
-- Matthew
Received on 2021-11-22 11:50:43