4 ms·

Why is a specific random generator should be in the standard at all? Random generators are quite a dangerous area. Picking one is not without compromises: Do y

by leni536 12y ago

Why is a specific random generator should be in the standard at all? Random generators are quite a dangerous area. Picking one is not without compromises: Do you want your PRNG fast? Or do you want it cryptographically secure? It could become obsolete in less time than expected. It's mostly true for CSPRNGs. Maybe that's why they are considering Mersenne Twister which is "good enough" for many use cases but not meant to be cryptographically secure. Sure, I'm using it right now for physics simulation and it's certainly good enough for that and it's hard to imagine a case where a 623-dimansionally equidistributed PRNG could fail. But it most certainly can if it can't be used for cryptography. It is much better than rand() though and one could argue that it will be good enough 99% of the time. The problem that you can't replace it if it ever becomes obsolete since some software depends on the predictability and still random like features of PRNGs (like game map generators, digital art, etc...). I think the one boost library they should standardize is boost's random device. PRNGs could become obsolete but "truly random" will always mean the same. However it's not trivial that one has access to a truly random source and in that case it should fall back to fail. At least it could kill the practice of seeding with time.

StephanTLavavej 12y ago
std::random_device is part of C++11, and VC's implementation guarantees that it's crypto-secure.
- tedunangst 12y ago
  The problem is the standard doesn't guarantee that, so people will inevitably read the standard, decide that they can't actually trust random_device, and then build their own, much worse version.
- nly 12y ago
  And on Linux you can pass the string "/dev/urandom" to the constructor
ygra 12y ago
> hard to imagine a case where a 623-dimansionally equidistributed PRNG could fail Well, there is the generalization and improvement of MT19937 in form of the WELL generators. They go beyond that, so there probably are cases where it's needed. > PRNGs could become obsolete but "truly random" will always mean the same I'd argue that far fewer people need truly random than those who just need a dice roll. There are those who work on crypto. They won't need anything in the C++ stdlib because there are libraries specifically for that. They also provide much more that is needed for programs utilizing cryptographic primitives. This group should know what they're doing and choosing, and if not should have no business writing such software. And they won't even accidentally pick MT. There are those who do numerical simulations. They neither need or can use a "truly-random" generator because submitting a paper with the words "to reproduce our results, grab the following 2 TiB file of random bits ..." is probably frowned-upon. Reproducability of a sequence is a feature, and a good one. Heck, quasi-random algorithms also have their place. In any case, you shouldn't do simulations with just a single PRNG either to rule out interactions between intricacies of your model/simulator and the PRNG. So people in this group are likely to use a framework or library that caters to their needs, too, which includes several different PRNGs (even obsolete ones for checking older results), distributions, special data structures needed for certain kinds of simulations (e.g. event queues), etc. This group also should know what they're doing and why, otherwise they shouldn't publish research at all. And then there is everyone else who just needs a random number every now and then. Maybe for shuffling a playlist, maybe for rolling a die. Having easy access to a PRNG that works well for a large number of use cases (they wouldn't have any idea what to choose anyway) is a major benefit to this group. They don't care about (or notice) the difference between pseudo-random and truly random (even though the latter sounds more impressive and the former somehow not random enough, even though anything that doesn't look random in the former case is often bad seeding, e.g. in a loop). They just want something to work. MT19937 is a very safe choice for this group, and as an added benefit, it's much better and often faster than LCGs.
lmm 12y ago
> Picking one is not without compromises: Do you want your PRNG fast? Or do you want it cryptographically secure? Many library functions involve tradeoffs. Do you want your malloc() fast? Or do you want it to minimize memory usage? Do you want your sorting function to be fast in the average case or be without pathological edge cases? A PRNG is no way unique in this respect. The standard library is ultimately a tool like any other; it should contain things that are useful. Of course there are compromises involved in any particular choice of PRNG, but that doesn't mean not including any is a better choice. My view is that a lot more things should be rigidly specified by the standards. The days of radically varying CPU architectures and radically different OSes are gone; these days underspecification mostly serves to trip programmers up. Standardizing the memory model was a huge step forward, and it's time for C++ to go further in that direction, time to start defining what was previously undefined or implementation-defined behaviour.
deleted 12y ago
[deleted]

by leni536 12y ago

StephanTLavavej 12y ago

std::random_device is part of C++11, and VC's implementation guarantees that it's crypto-secure.

tedunangst 12y ago
The problem is the standard doesn't guarantee that, so people will inevitably read the standard, decide that they can't actually trust random_device, and then build their own, much worse version.
nly 12y ago
And on Linux you can pass the string "/dev/urandom" to the constructor

ygra 12y ago

> hard to imagine a case where a 623-dimansionally equidistributed PRNG could fail Well, there is the generalization and improvement of MT19937 in form of the WELL generators. They go beyond that, so there probably are cases where it's needed. > PRNGs could become obsolete but "truly random" will always mean the same I'd argue that far fewer people need truly random than those who just need a dice roll. There are those who work on crypto. They won't need anything in the C++ stdlib because there are libraries specifically for that. They also provide much more that is needed for programs utilizing cryptographic primitives. This group should know what they're doing and choosing, and if not should have no business writing such software. And they won't even accidentally pick MT. There are those who do numerical simulations. They neither need or can use a "truly-random" generator because submitting a paper with the words "to reproduce our results, grab the following 2 TiB file of random bits ..." is probably frowned-upon. Reproducability of a sequence is a feature, and a good one. Heck, quasi-random algorithms also have their place. In any case, you shouldn't do simulations with just a single PRNG either to rule out interactions between intricacies of your model/simulator and the PRNG. So people in this group are likely to use a framework or library that caters to their needs, too, which includes several different PRNGs (even obsolete ones for checking older results), distributions, special data structures needed for certain kinds of simulations (e.g. event queues), etc. This group also should know what they're doing and why, otherwise they shouldn't publish research at all. And then there is everyone else who just needs a random number every now and then. Maybe for shuffling a playlist, maybe for rolling a die. Having easy access to a PRNG that works well for a large number of use cases (they wouldn't have any idea what to choose anyway) is a major benefit to this group. They don't care about (or notice) the difference between pseudo-random and truly random (even though the latter sounds more impressive and the former somehow not random enough, even though anything that doesn't look random in the former case is often bad seeding, e.g. in a loop). They just want something to work. MT19937 is a very safe choice for this group, and as an added benefit, it's much better and often faster than LCGs.

lmm 12y ago

> Picking one is not without compromises: Do you want your PRNG fast? Or do you want it cryptographically secure? Many library functions involve tradeoffs. Do you want your malloc() fast? Or do you want it to minimize memory usage? Do you want your sorting function to be fast in the average case or be without pathological edge cases? A PRNG is no way unique in this respect. The standard library is ultimately a tool like any other; it should contain things that are useful. Of course there are compromises involved in any particular choice of PRNG, but that doesn't mean not including any is a better choice. My view is that a lot more things should be rigidly specified by the standards. The days of radically varying CPU architectures and radically different OSes are gone; these days underspecification mostly serves to trip programmers up. Standardizing the memory model was a huge step forward, and it's time for C++ to go further in that direction, time to start defining what was previously undefined or implementation-defined behaviour.

deleted 12y ago

[deleted]