pcg-cpp
pcg-cpp copied to clipboard
imneme
Is this being proposed for standardization?
The best pseudo-random number generator in the C++ standard library is probably the Mersenne twister, which has well-known disadvantages such as being pretty memory heavy.
Do you know if anyone has started writing an spec to add this to the C++ standard library?
It is being considered for inclusion in Go (version 2) by @robpike
https://github.com/golang/go/issues/21835
@imneme : If I wrote a proposal for this, would you be okay with me writing "An Apache licensed implementation exists at github, with explicit approval from the author to vendorize the code into any project, the only change needed for compliance being the standard library underscore conventions and placing into the standard namespace."?
(I think the Apache license does grant that right, but I imagine it's more polite to get an explicit thumbs up.)
It's actually dual licensed as Apache and MIT. Apache lets people relax that there won't be any PCG-related patent claims coming from the authors, and MIT lets them do pretty much whatever they like.
We have implemented a subset of these as a component of Rust's random number library: rand_pcg.
One issue that came up is a difference in the construction of MCGs (e.g. pcg64_fast):
We decided to mirror the C version src, but standardisation or documentation by @imneme would be nice.
Nevertheless, we are able to match output on the test vector — because the seed 42 happens to already have the second-lowest bit set. (By the way, having test vectors on more than one seed would be nice.)
Our library also has seeding from byte vectors (forcing little-endian), from another RNG, and from a u64 value for all RNGs (using pcg32 to expand) as well as conversion of output to u32, u64 and byte-arrays for all RNGs. Including such functionality within a standard might be of interest.
@NAThompson, Apache 2 is not suitable for either libstdc++ or libc++, as it would place requirements on user code which included the library header and instantiated templates or called inline functions. That's why LLVM applies an extra exception to Apache 2 (and GCC applies a similar runtime exception to GPL3). MIT is fine though.
@NAThompson, Apache 2 is not suitable for either libstdc++ or libc++, as it would place requirements on user code which included the library header and instantiated templates or called inline functions. That's why LLVM applies an extra exception to Apache 2 (and GCC applies a similar runtime exception to GPL3). MIT is fine though.
Doesn't MIT require Attribution also in compiled binaries and consequently user applications that would be build with a standard library containing this?
It depends what variant you mean by "MIT" but the one that SPDX calls MIT only requires the copyright notice in "the software", meaning copies of the code.
https://spdx.org/licenses/MIT.html
I'm sure MIT would be compatible, but in any case, someone could always make their own implementation if they wanted.