Live data from Hacker News

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

pcg-random.org

51–60 of 67 posts

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

#51
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 languag…

C with "nothing left to take away" would be assembly.

C with nothing left to take away is portable assembly.

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

#52
post #36
post #35

Earlier quoted context omitted.

There are a lot of things the C and C++ standards allow implementations to do, such as making int 16 bits, using one's complement for signed integers, (in C) only making the first 31 characters of identifiers significant, (in C++) not allowing any identifiers longer than one character, except those in the standard library, et cetera. This is because they are designed to be portable to a wide variety of compilers and…

>This is because they are designed to be portable to a wide variety of compilers and target devices which might have limits that weren't envisioned at the time of writing the standard. That's not really the case here, is it? If anything the bug is in the standard.

> std::random_device may be implemented in terms of an implementation-defined pseudo-random number engine if a non-deterministic source (e.g. a hardware device) is not available to the implementation.

Windows has a non-deterministic source (IE: The function CryptGenRandom). Therefore, this is a bug in MingW's implementation. CryptGenRandom is hard to use, but that's no excuse for MingW's developers to be lazy.

Pointing at a "mistake" in the spec when the intent of the spec is extremely clear is laziness. Pure and simple.

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

#53

I wish they had mandated the algorithms used in the distributions. Even with the same generator initialized with the same seed, the normal distribution, for example, will give different results across platforms. At least the results of the generators are consistent across platforms.

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 to a precision of one part in 32 of the reciprocal of the square root of FRB. The value placed in FRT may vary between implementations and between different executions on the same implementation."

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

#54
post #41

Earlier quoted context omitted.

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

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

I don't think this is correct either. How would thinking a problem is "not important whatsoever" imply that someone must love or hate any potential solution? I couldn't care less how sports team X fixes their losing record, and yet your claim is that that would somehow correlate with me having extreme opinions (love or hate) about their decision to draft Player Y? Very much to the contrary, I'm apathetic about any solution, which is pretty much the definition of finding a problem "not important whatsoever".

Furthermore, I'm not even sure how "extreme opinions of the problem's importance" is relevant to what we're talking about. The original quote was "to the extent that anyone cares about [the problem] at all". That's anywhere from "I care a bit" to "I care a ton", not exclusively "I care a ton".

Finally, even if you weren't very wrong about the premise of what we're talking about: "X is correlated with Y" doesn't mean "X implies Y is a tautology (or close to one) because they're the same thing", which is the original statement I was responding to.

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

#55
post #53

I wish they had mandated the algorithms used in the distributions. Even with the same generator initialized with the same seed, the normal distribution, for example, will give different results across platforms. At least the results of the generators are consistent across platforms.

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?

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

#56
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…

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 as a language standard, which is where a lot of the challenge here comes from.

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

#57
post #32

Earlier quoted context omitted.

I thought NaCl was something related to browser plugins. What is the connection with crypto?

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

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

#59
post #41

Earlier quoted context omitted.

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

> 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). I don't think this is correct either. How would thinking a problem is "not important whatsoever" imply that someone must love or hate any potential solution? I couldn't care less how sports team X fixes their losing record, and yet your claim i…

>> correlated

> imply that someone must

Meh, correlation is not causation. Let's include apathy as a third extreme, for both problems and solutions.

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

#60
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 that would have been a real bummer for coders back before the Internet was really a thing. It's a pretty common thing to need and hard to implement.
Post reply on HN