News for hackers. Stuff that matters.
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)
Re:Modern C++ Won't Save Us by petters on Tuesday April 23, 2019 @01:27AM (#19725816)
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{}()}`.
Re:Modern C++ Won't Save Us by whyever on Tuesday April 23, 2019 @11:33AM (#19729611)
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.
Re:Modern C++ Won't Save Us by petters on Tuesday April 23, 2019 @02:22AM (#19726077)
You are completely right. That should be fixed
Re:Modern C++ Won't Save Us by madisfun on Tuesday April 23, 2019 @04:31AM (#19726592)
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.
Re:Modern C++ Won't Save Us by rcxdude on Tuesday April 23, 2019 @06:54AM (#19727292)
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.
Re:Modern C++ Won't Save Us by patrec on Tuesday April 23, 2019 @06:48AM (#19727267)
> 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, ...).

Re:Modern C++ Won't Save Us by sorenjan on Tuesday April 23, 2019 @08:29AM (#19727897)
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.
Re:Modern C++ Won't Save Us by whyever on Tuesday April 23, 2019 @11:14AM (#19729416)
> (rand() % (b - a)) + a;

This is no longer uniform, because it introduces a bias towards small numbers.

Re:Modern C++ Won't Save Us by sorenjan on Tuesday April 23, 2019 @12:49PM (#19730396)
Yes, it's less than ideal. But like I said, often good enough. Sometimes you just want a simple way to get something approximately random, the actual distribution might be unimportant.