11–20 of 26 posts
Earlier quoted context omitted.
No one uses the 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.
Sadly, people that don't know better use std::mt19937 all the time :-(.
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
Earlier quoted context omitted.
And the only reason is its cool name. Humans are weird
Well, it's in std. So there's an appeal to authority (the C++ language authors should be smart, right?) and convenience.
Earlier quoted context omitted.
No one uses the 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.
How did it get into the standard then?
Here is cppreference on PRNGs (note the various engines available) - https://www.cppreference.com/w/cpp/numeric/random.html You have to "know" how to combine the various options available to get an optimal sequence.
The Mersenne Twister (MT) was one of the best engines and was the default in many other languages/packages too. See "Applications" section in wikipedia - https://en.wikipedia.org/wiki/Mersenne_Twister
The author identified distribution problems with the 32-bit versions of MT (i am not sure whether similar problems exist with its 64-bit versions) and proposed a different one named "Permuted Congruential Generator (PCG)" which has now been adopted as the default by many of the languages/packages - https://en.wikipedia.org/wiki/Permuted_congruential_generato...
As you can now appreciate, the subject is mathematically complicated and the defaults chosen by the language/package implementer becomes the "most commonly used" and hence reference case. While this is good enough for most "normal" applications if you are doing any special simulations (Monte Carlo or otherwise) and/or specific Numerical Computations it is your responsibility to understand what it is that you need and program accordingly using the various options (if available) or roll your own.
Earlier quoted context omitted.
How did it get into the standard then?
You need to understand PRNGs to answer that question. It is complicated and nothing to do with C++ language itself. Here is cppreference on PRNGs (note the various engines available) - https://www.cppreference.com/w/cpp/numeric/random.html You have to "know" how to combine the various options available to get an optimal sequence. The Mersenne Twister (MT) was one of the best engines and was the default in many other…
The 64-bit version might be a bit faster (for certain workloads, on 64-bit hardware) than the 32-bit version, but still wastes the same space and has the same mathematical flaws.
PCG is still not perfect (128-bit math hurts, though the new DXSM variant at least reduces that to 128x64), but its mathematical properties are nicer than the xor* family (its main competitor), and both families are miles ahead of any other RNG out there.
Earlier quoted context omitted.
You need to understand PRNGs to answer that question. It is complicated and nothing to do with C++ language itself. Here is cppreference on PRNGs (note the various engines available) - https://www.cppreference.com/w/cpp/numeric/random.html You have to "know" how to combine the various options available to get an optimal sequence. The Mersenne Twister (MT) was one of the best engines and was the default in many other…
> (i am not sure whether similar problems exist with its 64-bit versions) and proposed a different one named "Permuted Congruential Generator (PCG)" The 64-bit version might be a bit faster (for certain workloads, on 64-bit hardware) than the 32-bit version, but still wastes the same space and has the same mathematical flaws. PCG is still not perfect (128-bit math hurts, though the new DXSM variant at least reduces t…
From https://en.wikipedia.org/wiki/Pseudorandom_number_generator
Even today, caution is sometimes required, as illustrated by the following warning in the International Encyclopedia of Statistical Science (2010).
The list of widely used generators that should be discarded is much longer [than the list of good generators]. Do not trust blindly the software vendors. Check the default RNG of your favorite software and be ready to replace it if needed. This last recommendation has been made over and over again over the past 40 years. Perhaps amazingly, it remains as relevant today as it was 40 years ago.
Earlier quoted context omitted.
Sadly, people that don't know better use std::mt19937 all the time :-(.
And the only reason is its cool name. Humans are weird
Earlier quoted context omitted.
Well, it's in std. So there's an appeal to authority (the C++ language authors should be smart, right?) and convenience.
There are still others in . Yet they always use the cool twister one with the funny numbers
Is it possible to initialize a prng in C++’s std correctly?
#include
#include
#include
std::mt19937 InitializeRng() {
std::array 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);
}
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).