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

11–20 of 67 posts

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

#11

Post by cperciva »

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…

Almost every program that relies upon the standard C runtime's random functions has a flawed random distribution

Right, and that function is a mistake in the C standard. It should have been omitted entirely.

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

#12

Post by cbsmith »

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_distribution uniform_dist(1, 6);
    const int random_value = uniform_dist(e);
The new process basically cuts the first two lines down to one, and uses a method call for a uniform distribution instead of creating an object for it. Is that really easier?

If so, then yeah, go with the idea of an empty constructor version of engines that will smartly seed from a random device, and add a mixin that does the magic of mapping all the different distributions in to methods.

I'm just wondering if that is somehow missing what is actually making life difficult for developers.

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

#13

Post by cbsmith »

cperciva wrote: post #11
cbsmith wrote: post #8

Earlier quoted context omitted.

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…

Almost every program that relies upon the standard C runtime's random functions has a flawed random distribution Right, and that function is a mistake in the C standard. It should have been omitted entirely.

That would have messed with C++'s goal of providing compatibility for C code.

Let's assume things had proceeded as you suggest though. We'd still not have a good solution for random number generation until the C++11 standard came out, and so we'd still have all the forces in place that gave rise to it and to the current mess.

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

#15

Post by cperciva »

cbsmith wrote: post #13
cperciva wrote: post #11

Earlier quoted context omitted.

Almost every program that relies upon the standard C runtime's random functions has a flawed random distribution Right, and that function is a mistake in the C standard. It should have been omitted entirely.

That would have messed with C++'s goal of providing compatibility for C code. Let's assume things had proceeded as you suggest though. We'd still not have a good solution for random number generation until the C++11 standard came out, and so we'd still have all the forces in place that gave rise to it and to the current mess.

You misunderstand me. I think random(3) should have been omitted from the C standard.

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

#16

Post by pcwalton »

cperciva wrote: post #15
cbsmith wrote: post #13

Earlier quoted context omitted.

That would have messed with C++'s goal of providing compatibility for C code. Let's assume things had proceeded as you suggest though. We'd still not have a good solution for random number generation until the C++11 standard came out, and so we'd still have all the forces in place that gave rise to it and to the current mess.

You misunderstand me. I think random(3) should have been omitted from the C standard.

What happens if you don't provide sensible, easy-to-use built-in implementations of things is that a diverse, bewildering ecosystem of different options tends to arise, confusing programmers who just want to get their job done and leading to a high probability of them picking the wrong thing.

See, for example, crypto before NaCl came around.

(NB: I'm not defending either this C++ standard or random(3).)

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

#17

Post by nickpsecurity »

cperciva wrote: post #15
cbsmith wrote: post #13

Earlier quoted context omitted.

That would have messed with C++'s goal of providing compatibility for C code. Let's assume things had proceeded as you suggest though. We'd still not have a good solution for random number generation until the C++11 standard came out, and so we'd still have all the forces in place that gave rise to it and to the current mess.

You misunderstand me. I think random(3) should have been omitted from the C standard.

I think they understand what you're saying. I agree with the other two that not having a clean, working standard means you get people rolling their own or digging out libraries. Quality varies wildly cuz we're talking random numbers with many issues resulting. People would still want a standard, in C or C++, that lets them do this correctly without problems.

So, it leads me to guess there's two ways the the C++ situation would've been made unnecessary:

1. Leave it out of C itself but pro's build and maintain a de facto standard in form of a library as easy to use as random and widely available. Can even be OS random facilities cleanly wrapped.

2. Put a good one in C standard. Becomes the standard de facto and officially.

Preconditions didn't exist or convenience prevailed. So, now there's a new attempt at dealing with the mess. That's my guess as a person looking on from the outside rather than a user of all these tools. Just to be clear on that part.

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

#18

Post by cperciva »

pcwalton wrote: post #16
cperciva wrote: post #15

Earlier quoted context omitted.

You misunderstand me. I think random(3) should have been omitted from the C standard.

What happens if you don't provide sensible, easy-to-use built-in implementations of things is that a diverse, bewildering ecosystem of different options tends to arise, confusing programmers who just want to get their job done and leading to a high probability of them picking the wrong thing. See, for example, crypto before NaCl came around. (NB: I'm not defending either this C++ standard or random(3).)

What happens if you don't provide sensible, easy-to-use built-in implementations of things is that a diverse, bewildering ecosystem of different options tends to arise, confusing programmers who just want to get their job done and leading to a high probability of them picking the wrong thing.

Sure... but what happens if you do specify that implementations should be built-in is that a diverse, bewildering ecosystem of broken implementations get built in, and so people who know what they're doing end up eschewing the built-in implementations in favour of shipping with an implementation which they know works. And ultimately you have a standard function which everybody provides for compatibility purposes, but which nobody should ever use. See, for example, random(3).

Functionality should be added to standards when we can be confident that every implementation in the next 100 years will get it right, and no sooner.

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

#19

Post by MereInterest »

One thing that I would like to have is a common base class that can be passed around. Often, I would like for a function orclass to be told which engine to use, quite useful for unit testing, or for having reproducible results. As it is, the only way to accept multiple different engines is by templating over the engine type. This ends up requiring that every part of the code that uses the random engine be brought into the header file, and classes need to be templated on the engine type to store a reference to the engine.

I was kind of hoping that the `random_generator` class would be a templated class derived from a non-templated base class, so that it could be used in this manner. Looking over it, I can see why it doesn't, as many of the methods are much, much more useful as templated methods, which do not interact nicely with virtual functions.

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

#20

Post by cbsmith »

cperciva wrote: post #15
cbsmith wrote: post #13

Earlier quoted context omitted.

That would have messed with C++'s goal of providing compatibility for C code. Let's assume things had proceeded as you suggest though. We'd still not have a good solution for random number generation until the C++11 standard came out, and so we'd still have all the forces in place that gave rise to it and to the current mess.

You misunderstand me. I think random(3) should have been omitted from the C standard.

Ah well. I could see where that'd not have been an entirely bad thing.

However, eventually you need to provide something that works. There is some value in having a portable way to generate random numbers. I can't think of a language that doesn't define one, and I don't think that is by accident.

Post reply on HN