Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C++ community is polarized about C++11's random-number facility

pcg-random.org

Post reply on HN
Print view View original

61–67 of 67 posts

Re: The C++ community is polarized about C++11's random-number facility

#61

Post by JoachimSchipper »

cbsmith wrote: post #56
JoachimSchipper wrote: post #49

Earlier quoted context omitted.

random(3) is clearly bad; but contrast this proposal with the simplicity (and security) of OpenBSD's arc4random(), arc4random_uniform(), arc4random_buf().

arc4random_uniform() is the only one that really addresses the matters in this proposal, and arc4random_uniform() can't handle values larger than 2^32-1 (and, in fact, thanks to the wonders of overflow, might do some unfortunate things in a variety of cases), and won't produce values greater than 2^32-2. So yeah, not exactly addressing the matter. Of course, that whole arc4* library doesn't have the same challenges a…

You're not wrong, but let me be more explicit: the problems arc4random_*() solves are the ones I feel are important: good-quality random with no corner cases (e.g. still reliable if you run out of file descriptors, at least on OpenBSD). pick() or shuffle() really are nice, but I'm much more scared of predictable-by-default or predictable-in-corner-cases RNGs than of errors in a hand-rolled pick().

(I don't write code where e.g. std::poisson_distribution would be useful, so I don't feel I have the background to have an opinion on that part of the proposal.)

Overflow is something that the programmer always has to keep in mind, unfortunately.

Re: The C++ community is polarized about C++11's random-number facility

#62

Post by cbsmith »

JoachimSchipper wrote: post #61
cbsmith wrote: post #56

Earlier quoted context omitted.

arc4random_uniform() is the only one that really addresses the matters in this proposal, and arc4random_uniform() can't handle values larger than 2^32-1 (and, in fact, thanks to the wonders of overflow, might do some unfortunate things in a variety of cases), and won't produce values greater than 2^32-2. So yeah, not exactly addressing the matter. Of course, that whole arc4* library doesn't have the same challenges a…

You're not wrong, but let me be more explicit: the problems arc4random_*() solves are the ones I feel are important: good-quality random with no corner cases (e.g. still reliable if you run out of file descriptors, at least on OpenBSD). pick() or shuffle() really are nice, but I'm much more scared of predictable-by-default or predictable-in-corner-cases RNGs than of errors in a hand-rolled pick(). (I don't write code…

Generics and boxed types make overflow a non-concern.

The proposal doesn't really care much about distributions. It's intended for people who don't care about random distributions.

Re: The C++ community is polarized about C++11's random-number facility

#63

Post by JoachimSchipper »

cbsmith wrote: post #62
JoachimSchipper wrote: post #61

Earlier quoted context omitted.

You're not wrong, but let me be more explicit: the problems arc4random_*() solves are the ones I feel are important: good-quality random with no corner cases (e.g. still reliable if you run out of file descriptors, at least on OpenBSD). pick() or shuffle() really are nice, but I'm much more scared of predictable-by-default or predictable-in-corner-cases RNGs than of errors in a hand-rolled pick(). (I don't write code…

Generics and boxed types make overflow a non-concern. The proposal doesn't really care much about distributions. It's intended for people who don't care about random distributions.

FWIW: generics and boxed types allow you to write code without overflow, but there's plenty of real-world C++ that's full of overflows. Good C uses a small number of types and also avoids overflow...

Although we have different concerns, it's clear that a lot of thought has been put into the proposal, and it seems to achieve its/your goals pretty well. Don't let my concerns put you off.

Re: The C++ community is polarized about C++11's random-number facility

#64

Post by Veedrac »

cbsmith wrote: post #45
Veedrac wrote: post #43

Earlier quoted context omitted.

See the author's comments on very similar code here: https://www.reddit.com/r/cpp/comments/31857s/random_number_g... > One minor issue is that you’re using `default_random_engine`, which in some systems may be a LCG with a tiny 32-bit state. If so, you’ll have an RNG with a tiny period. That’s why Stephan recommends[1] that you explicitly use the Mersenne Twister. Of course, it might be something better, with more st…

I think the solution for platforms which use bad default_random_engine's is for said platforms to stop doing that. ;-) Seriously, the whole point of platform defaults is that they make appropriate choices for the platform. Sure, you can define your own engine, but that's exactly what the original API gives you...

You could say that about a lot of platform defaults. Sadly it's still our responsibility to avoid the bad ones.

Re: The C++ community is polarized about C++11's random-number facility

#65

Post by Someone »

api_or_ipa wrote: post #55
Someone wrote: post #53

Earlier quoted context omitted.

Is that feasible for distributions over the reals across CPU architectures or maybe even revisions? FPUs typically do not compute the best possible result for floating point operations. Also, instructions like 'estimate one over square root' have multiple 'correct' answers. Edit: https://www-01.ibm.com/support/knowledgecenter/#!/ssw_aix_71... shows things are worse: "The estimate placed into register FRT is correct t…

Is this an indication of a randomly seeded Newtown's method?

But why would they? My guess would be that they don't bother to clear a carry flag or are computing the estimate using a few extra significant bits, and do not bother to initialize those at start, but that's 100% guess. I know very little about designing CPUs.

Re: The C++ community is polarized about C++11's random-number facility

#66

Post by cbsmith »

Veedrac wrote: post #64
cbsmith wrote: post #45

Earlier quoted context omitted.

I think the solution for platforms which use bad default_random_engine's is for said platforms to stop doing that. ;-) Seriously, the whole point of platform defaults is that they make appropriate choices for the platform. Sure, you can define your own engine, but that's exactly what the original API gives you...

You could say that about a lot of platform defaults. Sadly it's still our responsibility to avoid the bad ones.

Exactly. Working around it in the standard is the wrong way to do it though. You send what the standard requires, and maybe the bad guys are standards compliant, but there is no point in bending over backwards to work around a platform that is going to find a way to mess it up anyway.

Re: The C++ community is polarized about C++11's random-number facility

#67

Post by orange_utha »

cpach wrote: post #57
ori_b wrote: post #32

Earlier quoted context omitted.

Name collisions: http://nacl.cr.yp.to/ Although, I've never actually seen it used in the wild.

Threema use it. (I don’t know if they use it in a sane way though.)

They do. There's an audit that confirms it, and you can use Validation Logging to verify it yourself: https://threema.ch/validation/
Post reply on HN