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

41–50 of 67 posts

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

#41

Post by isolate »

wutbrodo wrote: post #39
GFK_of_xmaspast wrote: post #6

"To the extent that anyone cares about C++11's random-number facility at all, the C++ community is polarized between two views—one that likes it, and one that hates it." Isn't that almost a tautology? "People who care about X either love it or hate it".

No. You can recognize the importance of something and care about it a lot while thinking it's (eg) mediocre. Thinking a problem is important and having an extreme opinion of a solution are entirely different axes.

In my experience, having an extreme opinion of a problem's importance (very important, not important whatsoever) is correlated with having an extreme opinion of a solution (love it, hate it).

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

#42

Post by ori_b »

cornstalks wrote: post #37
ori_b wrote: post #33

Why not specify the algorithm for std::rand? The specification, as far as I'm aware, gives no guarantees at all about the algorithm used. Why not just specify a good algorithm instead of adding a new function?

std::rand has global state. Specifying the algorithm doesn't fix that. And this lets you (easily) generate more than just integers in the range [0, INT_MAX]. std::rand doesn't have that level of convenience. There are all sorts of inconveniences with std::rand, and it looks like this solves the vast majority of them.

> std::rand has global state. Specifying the algorithm doesn't fix that.

Adding other functions also doesn't fix std:rand. People use std::rand. They will continue to use std::rand, unless it's removed. And even then they'll keep using it, because implementations will add it back in for compatibility.

There's already a simple, half baked, crude random number generator. It's possible to fix it so that it provides at least acceptable randomness, and isn't complete junk. Doing this breaks nothing.

Why add another similar function with similar API issues?

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

#43

Post by Veedrac »

cbsmith wrote: post #12
dicroce wrote: post #7

I like this proposal and I agree that randint is a bad idea.

I think there is a case to be made for doing both. The one advantage of randint is that it makes for a convenient migration path for those relying on std::rand() and friends. I honestly am a bit at a loss though in terms of understanding how this proposal makes things significantly easier for programmers. Absent this proposal, you would write: std::default_random_engine e(std::random_device{}); std::uniform_int_distr…

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 state.

> But what’s really wrong with it is that you use a single 32-bit integer to seed the RNG. If you’re using the Mersenne Twister, you’re using four bytes of state to try to seed 624 bytes. It’ll work, but it’s way worse than what the Python code does; Python uses 624 bytes of actual entropy rather than four bytes.

[1]: https://www.reddit.com/r/cpp/comments/31857s/random_number_g...

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

#44

Post by cbsmith »

vitalyd wrote: post #27
cbsmith wrote: post #25

Earlier quoted context omitted.

It is entirely possible to write a highly configurable interface with sane defaults. Indeed, the proposal in this article goes a long way in that direction.

Sometimes the right defaults depend on context unavailable to the low level library author. But irrespective of who provides the higher level API, the bottom line is that there needs to be an API that's most flexible when the flexibility is warranted. This is really in reference to Colin's "nothing more to add" remark.

If there is some other context that is unavailable to low the level author, then that default should be provided by whatever higher level is providing said context. C++'s namespaces provide a super convenient mechanism to make that work smoothly.

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

#45

Post by cbsmith »

Veedrac wrote: post #43
cbsmith wrote: post #12

Earlier quoted context omitted.

I think there is a case to be made for doing both. The one advantage of randint is that it makes for a convenient migration path for those relying on std::rand() and friends. I honestly am a bit at a loss though in terms of understanding how this proposal makes things significantly easier for programmers. Absent this proposal, you would write: std::default_random_engine e(std::random_device{}); std::uniform_int_distr…

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...

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

#46

Post by cbsmith »

com2kid wrote: post #29
cbsmith wrote: post #12

Earlier quoted context omitted.

I think there is a case to be made for doing both. The one advantage of randint is that it makes for a convenient migration path for those relying on std::rand() and friends. I honestly am a bit at a loss though in terms of understanding how this proposal makes things significantly easier for programmers. Absent this proposal, you would write: std::default_random_engine e(std::random_device{}); std::uniform_int_distr…

The current way separates out what will be gotten back from the engine from the actual invocation. In comparison, the proposal lets me look at one line and know what will be returned: rng.uniform(1,17) I know exactly what to expect. Compare that to: uniform_dist(e); Unless the variable is named very well ("UniformDistOneToSix"?), I don't know what that line does. Not to mention, what if I want to roll a bunch of numb…

I'd just call it "from_one_to_six".

I guess if it is really a mystery, you could just always do:

    std::uniform_int_distribution{1, 6}(e);
...and use some typedefs to avoid it being quite so verbose.

I'm not sure I grok the bunch of numbers in a row scenario. Usually in that case I'd imagine you'd want to create a bunch of numbers with a consistent distribution, which is exactly why you have the structure you want. If not, you can always create new distributions in an ad hoc fashion (exactly why it is good that the parameters for a distribution are NOT template parameters). Instantiating distributions isn't costing you anything here. It's just a transient struct with a handful of fields... though if you use it for more than one call, it might somehow be more efficient (doubtful, but conceivable).

In practice, you pretty much always end up with something that holds the engine inside it, and you can always decorate it with methods like:

    int roll_die(){ return std::uniform_int_distribution{1, 6}(e); }
...or alternatively:

    template 
    T uniform(const T begin, const T end) { return std::uniform_int_distribution{begin, end}(e); }

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

#47

Post by cornstalks »

ori_b wrote: post #42
cornstalks wrote: post #37

Earlier quoted context omitted.

std::rand has global state. Specifying the algorithm doesn't fix that. And this lets you (easily) generate more than just integers in the range [0, INT_MAX]. std::rand doesn't have that level of convenience. There are all sorts of inconveniences with std::rand, and it looks like this solves the vast majority of them.

> std::rand has global state. Specifying the algorithm doesn't fix that. Adding other functions also doesn't fix std:rand. People use std::rand. They will continue to use std::rand, unless it's removed. And even then they'll keep using it, because implementations will add it back in for compatibility. There's already a simple, half baked, crude random number generator. It's possible to fix it so that it provides at l…

What is this "similar function" with "similar API issues"?

C++11's random utilities and O'Neill's randutils aren't similar to std::rand at all. They're totally different beasts from std::rand.

Making std::rand a decent RNG would probably make the world a better place. I'm not disagreeing with that. But even if std::rand used a decent algorithm, it's still a suboptimal API.

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

#48

Post by cbsmith »

Veedrac wrote: post #43
cbsmith wrote: post #12

Earlier quoted context omitted.

I think there is a case to be made for doing both. The one advantage of randint is that it makes for a convenient migration path for those relying on std::rand() and friends. I honestly am a bit at a loss though in terms of understanding how this proposal makes things significantly easier for programmers. Absent this proposal, you would write: std::default_random_engine e(std::random_device{}); std::uniform_int_distr…

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…

Now I finally get it. C++11's seed sequences are not compatible with std::random_device. I'd been using the pre-C++11 boost::random and hadn't realized there was this subtle difference.

That is super annoying.

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

#49

Post by JoachimSchipper »

cbsmith wrote: post #8
cperciva wrote: post #5

Features like this make me think that C++ is designed by people who think that perfection is reached when there is nothing more to add. As a C developer, I side with Antoine de Saint Exupéry.

Sigh... Too often that criticism is leveled at C++ without an understanding of the terrain. I don't think C developers should be sitting on a high horse on this one. C represents a pretty good example of the problem. Almost every program that relies upon the standard C runtime's random functions has a flawed random distribution, so any correct program completely bypasses that infrastructure and/or has a ton of additi…

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

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

#50

Post by ubernostrum »

cperciva wrote: post #5

Features like this make me think that C++ is designed by people who think that perfection is reached when there is nothing more to add. As a C developer, I side with Antoine de Saint Exupéry.

C with "nothing left to take away" would be assembly. Why don't you switch from C to assembly? Or figure out what you get when there's nothing left to take away from assembly?

Or maybe your idea of "just the right amount of stuff" is different from someone else's idea of that, and we could be thankful that the world is able to accommodate more than one opinion on this by providing us with multiple programming languages we can use according to our needs and preferences.

Post reply on HN