Date: Fri, 19 Nov 2021 15:50:57 +0100
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
> > 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. 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
> 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
> > 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. 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
Received on 2021-11-19 08:51:04