Date: Fri, 19 Nov 2021 10:15:07 -0500
On Fri, Nov 19, 2021 at 9:51 AM Dimitrij Mijoski via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Wed, 2021-11-17 at 23:22 -0500, Arthur O'Dwyer wrote:
>
> If you seed Xoshiro256** with a merely 32-bit seed, then use it to produce 32 bits, it'll never produce 7, or 13 — or any of 3760 other numbers between 1 and 10000. But guess what? My test program to verify that ran in 11 seconds flat. The same thing for MT19937 (which I had to run to produce my comments above) takes literally hours. MT19937 is just awful if what you care about is getting random numbers out of it in a timely fashion. It's the Java of PRNGs.
>
>
> This is just one more argument that that "test", i.e. distribution of the first outputs after seeding, is not a good test for the quality of any PRNG. The P in PRNG has meaning, of course they are not perfect, they are pseudo-random. They are designed to give uniformity after multiple calls after seeding. See my previous comment here https://lists.isocpp.org/std-proposals/2021/11/3354.php
The idea that you shouldn't expect reasonable randomness from an RNG
until you prime the pump by extracting some number of random bits from
it is ridiculous. That's the *entire point* of seeding the RNG: to
prime the pump so that you can get good randomness from the first bit
you extract.
>
> So what is the proper way to seed this generator? Well, a single integer is actually good for the majority of users, and if you really need wider state space, useseed_seq with only few integers.
>
>
> If you're already paying for heap-allocation (std::seed_seq is basically std::vector with extra steps), then you might as well fill up the seed. I claim there's no good reason to "under-seed" a generator. If you're only going to use 256 bits of seed, then you should just use a generator with 256 bits of state in the first place.
>
> > I personally think that filling the whole state (624 integers) with values from random_device
> > is wrong because it wastes the system entropy. If not wrong then slow and pointless.
>
> Sure, but that's a problem with MT19937 asking for too much seed material, not a problem with the core idea of "fully seeding" a generator.
>
>
> This is definitely debatable, you can not just claim something, you need to give some arguments.
His point is pretty straightforward. If an RNG has a gigantic seed,
then that's a problem with the RNG, not with the person wanting to
fill up *whatever* seed an RNG has. Logically, it makes no sense not
to fill up the entire RNG seed.
And note, we're not taking away the ability to pick however much
randomness you want. We're making it easier to fill up the entirety of
the seed with randomness. You're effectively saying that people
shouldn't want that, but the only reason not to do it is because some
RNGs have gigantic seeds. He's saying that this is a problem with the
RNG, not with the concept of filling up the seed entirely.
>Just because Mersenne twister has large internal state, it doesn't mean all of it needs to be seeded with std::random_device. std::seed_seq was invented for a reason. Seeding with 128 bits is way way enough for any PRNG. I was told that 2^128 is more than all of the atoms in the universe. I gave my additional arguments against overuse of std::random_device in this comment https://lists.isocpp.org/std-proposals/2021/11/3356.php
Also: this is a mailing list. We can see the entire conversation; you
don't need to link to particular parts of it.
<std-proposals_at_[hidden]> wrote:
>
> On Wed, 2021-11-17 at 23:22 -0500, Arthur O'Dwyer wrote:
>
> If you seed Xoshiro256** with a merely 32-bit seed, then use it to produce 32 bits, it'll never produce 7, or 13 — or any of 3760 other numbers between 1 and 10000. But guess what? My test program to verify that ran in 11 seconds flat. The same thing for MT19937 (which I had to run to produce my comments above) takes literally hours. MT19937 is just awful if what you care about is getting random numbers out of it in a timely fashion. It's the Java of PRNGs.
>
>
> This is just one more argument that that "test", i.e. distribution of the first outputs after seeding, is not a good test for the quality of any PRNG. The P in PRNG has meaning, of course they are not perfect, they are pseudo-random. They are designed to give uniformity after multiple calls after seeding. See my previous comment here https://lists.isocpp.org/std-proposals/2021/11/3354.php
The idea that you shouldn't expect reasonable randomness from an RNG
until you prime the pump by extracting some number of random bits from
it is ridiculous. That's the *entire point* of seeding the RNG: to
prime the pump so that you can get good randomness from the first bit
you extract.
>
> So what is the proper way to seed this generator? Well, a single integer is actually good for the majority of users, and if you really need wider state space, useseed_seq with only few integers.
>
>
> If you're already paying for heap-allocation (std::seed_seq is basically std::vector with extra steps), then you might as well fill up the seed. I claim there's no good reason to "under-seed" a generator. If you're only going to use 256 bits of seed, then you should just use a generator with 256 bits of state in the first place.
>
> > I personally think that filling the whole state (624 integers) with values from random_device
> > is wrong because it wastes the system entropy. If not wrong then slow and pointless.
>
> Sure, but that's a problem with MT19937 asking for too much seed material, not a problem with the core idea of "fully seeding" a generator.
>
>
> This is definitely debatable, you can not just claim something, you need to give some arguments.
His point is pretty straightforward. If an RNG has a gigantic seed,
then that's a problem with the RNG, not with the person wanting to
fill up *whatever* seed an RNG has. Logically, it makes no sense not
to fill up the entire RNG seed.
And note, we're not taking away the ability to pick however much
randomness you want. We're making it easier to fill up the entirety of
the seed with randomness. You're effectively saying that people
shouldn't want that, but the only reason not to do it is because some
RNGs have gigantic seeds. He's saying that this is a problem with the
RNG, not with the concept of filling up the seed entirely.
>Just because Mersenne twister has large internal state, it doesn't mean all of it needs to be seeded with std::random_device. std::seed_seq was invented for a reason. Seeding with 128 bits is way way enough for any PRNG. I was told that 2^128 is more than all of the atoms in the universe. I gave my additional arguments against overuse of std::random_device in this comment https://lists.isocpp.org/std-proposals/2021/11/3356.php
Also: this is a mailing list. We can see the entire conversation; you
don't need to link to particular parts of it.
Received on 2021-11-19 09:15:21