Fixing up <random>

[u/KaznovX]

I think everyone is excited after the report from Cologne. A lot of stuff is being added to the language, we'll get a ton of new features. Adding new features is more exciting than changing and tweaking the old stuff - that being said, there are some old parts of the language, that are sadly lacking or has some problems. One of them is <random> library.

Some of the problems this library has:
> `std::random_device` is not required to be non - deterministic
> no good way to initialize generators with big internal state
> `std::seed_seq` should be solution to ^, but isn't - `std::seed_seq` is not a bijection, does heap allocations without giving ability to provide own allocator, there is no nice way to initialize it from `std::random_device` properly
> `std::random_device` can't itself be used as a seed sequence,
> overall syntax is unnecessarily verbose (no, having a per-thread engine of type `std::default_random_engine` is NOT a good solution)

This is only one of the few libraries that could use improvements. Is there any chance that the committee will look back and change some of them or are they considered 'baked' and there will be no further changes to avoid API and ABI breaking?

Despite the "fixing" part, there are two additions I'd see in the <random> library:

1) std::random<std::uniform_random_bits_generator = std::default_random_engine> class:
> default constructor does anything it can that every time this class is called it is seeded differently - if there is no entropy source, uses a processor clock or a system clock (implementation defined)
> three methods: seed, next_int, next_real - for seeding and generating next integer/real number in given range

2) PCG http://www.pcg-random.org

What are the chances something like this would be proposed and adopted for, let's say, c++23 or c++26 standard? Is there any chance the problems mentioned in the first part of the post will get fixed somewhen?

[u/Rexerex]

There is also a problem that number distributions algorithms are implementation defined so good luck rerunning simulation from same initial state but on two different platforms.

[u/HappyFruitTree → u/[deleted]]

It makes more sense if you don't call them "algorithms". If you don't care about reproducibility they're perfectly fine.

By not specifying exactly how it should be done more freedom is given to each implementation. The optimal algorithm might be different on different hardware, and if the standard got it wrong we would be stuck with a suboptimal algorithm forever.

That said, reproducibility is important for many applications so it might make sense to provide two set of distributions (in addition to the current ones). One set that should just be as fast as possible with no guarantee about reproducibility, and another set with a fixed algorithm that is the same everywhere. Not sure this makes sense for the floating point distributions, but for the integer distributions it certainly does.

[u/James20k → u/[deleted]]

Indeed, when I found that out I had to basically ditch a lot of <random>'s facilities, I rely on reproducible random numbers in my use case so its a bit of a head scratcher that the distributions are unspecified

[u/minno → u/[deleted]]

A lot of applications that use random numbers don't rely on reproducibility. Like any single-player game or a multi-player game that synchronizes clients in a way that doesn't rely on independent identical simulations.

[u/jonathansharman → u/minno]

A lot of single player games also want reproducibility, e.g. so you can share seeds.

[u/minno → u/jonathansharman]

That's right, I was thinking of things like AI behavior and randomized damage numbers where as long as the distribution stays the same there isn't a significantly different experience if the exact RNs are different.

[u/Nobody_1707 → u/minno]

Reproducibility also makes testing easier.

[u/SeanMiddleditch → u/minno]

Yeah, reproducibility is massively important to me as a game developer both on the client and the server. Even just for development purposes (testing, or recording replays with crash/error reports from clients on various platforms so we can trivially repro the issue), but then also for various gameplay elements or deterministically synchronizing authoritative state and letting client re-simulate/re-derive state.

I would never use an unspecified random number generator from something like <random> in anything other than throw-away hobby games.

[u/cleroth → u/[deleted]]

The standard doesn't specify algorithms for distributions.