Re:Modern C++ Won't Save Us
by blt on Tuesday April 23, 2019 @12:56AM
(#19725706)
How is the prng over engineered? I agree its a little clunky for casual use but it makes all the right decisions, imo, for serious use of prngs (e.g. reproducible experiments for Monte Carlo methods in simulation and statistics)
[ Parent
| on HN ]
Initializing the mersenne twister is really hard: https://github.com/PetterS/monolith/blob/master/minimum/core...
Edit: There are two links in the code with more info.
Re:Modern C++ Won't Save Us
by netheril96 on Tuesday April 23, 2019 @03:11AM
(#19726270)
Most other random libraries, in whatever languages, do not even offer the option of this "right" version of initialization. They all just seed with a 32-bit integer. If you are content with those libraries, you should be content with a simple `std::mt19937{std::random_device{}()}`.
I don't think this is true for modern languages.
Rust seeds the whole state by default: https://docs.rs/rand/0.6.5/rand/
Julia seems to seed 128 bits: https://github.com/JuliaLang/julia/blob/5741c7f53c5ea443bbd7...
However, your statement seems to apply to old languages:
C# uses only 32 bits and the time for seeding: https://docs.microsoft.com/en-us/dotnet/api/system.random?vi...
Java only supports 48 bit seeds: https://docs.oracle.com/javase/8/docs/api/java/util/Random.h...
Re:Modern C++ Won't Save Us
by dearrifling on Tuesday April 23, 2019 @02:04AM
(#19725974)
One shouldn't std::move in a return. Returning a local is already automatically an rvalue, however explicitly moving it disables copy elision.
You are completely right. That should be fixed
Mersenne Twister has a huge state, and if you have to use the MT (you need a very long period), you will probably want to be able to initialize it properly. For the common use case is a linear congruential generator which is initialized with just one integer.
Re:Modern C++ Won't Save Us
by GoblinSlayer on Tuesday April 23, 2019 @11:51AM
(#19729778)
Huh? You can't possibly need a period 2^19937-1.
The problem is there's no easy to use sensible defaults, just a confusing bunch of options with a bunch of apparently easy but subtely wrong ways to use it. Having the power is useful, but I would also just like a rand() (or better a randrange()) which actually works.
> it makes all the right decisions, imo, for serious use of prngs
Apart from an awkward API that's hard to use correctly, Mersenne Twister which is basically the main generator has been obsolete for years (bad quality RNs, slow, huge state, ...).
What's the modern C++ equivalent to C's
(rand() % (b - a)) + a;
or Python's random.randint(a, b)
Easy to use and often good enough.> (rand() % (b - a)) + a;
This is no longer uniform, because it introduces a bias towards small numbers.