C++ Seeding Surprises (2015)

C++ Seeding Surprises (2015)(pcg-random.org)

36 points by vsbuffalo 327 days ago | 25 comments

cjfd 324 days ago |

This talks about 'bad' seeding quite a lot. But it really depends on what you need what is bad and what is good. Sometimes you need to have a reproducible program so you need to write the random number generator yourself and/or otherwise fix the algorithm. Then you can use '5' as the seed. This is quite often good enough for simulations. Sometimes you want to create cryptographic randomness. Then you need to somewhere find some seed of true randomness that is not guessable. In a computer game where the level needs some random elements just seeding the random number generator with the current time might be fine. And so on.

quietbritishjim 323 days ago | |

I don't think it disputes that sometimes using a fixed small number is a good seed for reproducibility. The point is just, if you do happen to be in the other camp, where you actually want to populate the full state of the RNG using hardware randomness, C++ does not give you an obvious way to do that.

rramadass 324 days ago |

Relevant: A old Reddit discussion by the same author - https://old.reddit.com/r/cpp/comments/32u4m7/the_behavior_of...

nynx 324 days ago |

Is it possible to initialize a prng in C++’s std correctly?

sltkr 323 days ago | |

My standard code for doing this looks like this:

    #include <algorithm>
    #include <array>
    #include <random>
    
    std::mt19937 InitializeRng() {
      std::array<unsigned int, 624> seed_data;
      std::random_device dev;
      std::generate_n(seed_data.data(), seed_data.size(), std::ref(dev));
      std::seed_seq seq(std::begin(seed_data), std::end(seed_data));
      return std::mt19937(seq);
    }

This generates seed_seq with 19968 bits of random data, which is enough for the 19937 bits of Mersenne Twister internal state.

Note that 19668 bits of random data is overkill; something like 256 or 128 bits would probably enough for practical purposes. But I believe there is no real need to limit the amount of data extracted from a random source. Modern operating systems are pretty good at generating large amounts of random data quickly. But if this is a concern, just change 624 to 4/8/16/32 for 128/256/512/1024 bits of entropy. In practice, I don't think you'll notice a difference either in randomness or initialization speed.

edit: also, if performance is a concern, consider changing mt19937 to mt19937_64, which is the 64-bit variant of mt19937 that is incompatible (generates different numbers) but is almost twice as fast on 64-bit platforms (i.e. most platforms today).

loeg 324 days ago | |

If you're aware/concerned about seeding, you probably aren't using the C++ std prng (mt19937) anyway -- other prngs have desirable properties like vastly smaller state, better performance, or cryptographic security.

on_the_train 324 days ago | |

No one uses the <random> header as it's cursed and the usual cult of backwards compatibility ensures it'll stay that way.

There are several high quality alternatives that people use.

nynx 324 days ago | | |

How did it get into the standard then?

thechao 324 days ago | | |

I've found it easier to write my own PRNG than to use the std. Using the std PRNG is about as buggy as my implementation, so the trade-off is reasonable. I usually need non-cryptographically strong PRNGs, so xorshift128+ is sufficient.

loeg 324 days ago | | |

Sadly, people that don't know better use std::mt19937 all the time :-(.

atemerev 323 days ago |

If you want reproducibility and statelessness, there's random123 which I highly recommend. Particularly useful for GPU code.

(Not cryptographically secure, but passes all statistical tests you throw at it).

b0a04gl 324 days ago |

found one more flakiness over cross platform, when seed mt19937 same way on linux and windows, same compiler, same code... but problem is std::random_device or libc internals differ under the hood. some platforms do random_device as true hardware entropy, others fake it or seed from diff system sources. so seed retrieved isn't stable cross platform. that means mt19937 starts from diff states, causing different random sequences

it's not a bug in mt19937 itself, it's how random_device (or libc randomness) works differently across environments. makes cross platform tests flaky even when logic is rock solid

std::random_device rd; // might differ per platform

std::mt19937 gen(rd()); // seed depends on rd output

std::uniform_int_distribution<> dist(1, 100);

int random_number = dist(gen); // different on linux vs windows tho same code

senkora 323 days ago | |

Why not just run your tests with a fixed seed? e.g.

    std::mt19937 gen(42);
    std::uniform_int_distribution<> dist(1, 100);
    int random_number = dist(gen);

jhasse 323 days ago | | |

uniform_int_distribution differs between compilers/platforms! Don't use it if you don't want true randomness.

#include <algorithm> #include <array> #include <random> std::mt19937 InitializeRng() { std::array<unsigned int, 624> seed_data; std::random_device dev; std::generate_n(seed_data.data(), seed_data.size(), std::ref(dev)); std::seed_seq seq(std::begin(seed_data), std::end(seed_data)); return std::mt19937(seq); }