Platform-independent random numbers [using stdlib copy]

[halflearned]

Third -- and hopefully final -- attempt at #379.

In our last meeting, we decided that we should try once again to copy from boost a way that 1) would not bloat the third party dependencies with hundreds of boost files, but also 2) be easily reproducible. Unfortunately, I wasn't able to achieve both goals simultaneously. Boost has a very complex type system, and I wasn't able to extricate the necessary functions without bringing a few hundred boost files along.

Instead, I decided to take a final look at standard library's <random> and noticed that most of the dependencies came from operator<<. Having removed those methods, it was not hard to pull the necessary classes from the standard library.

Major changes

• Two new files in third_party: grfstd/algorithm.hpp and grfstd/random.hpp, which are nearly exact copies of the relevant parts of algorithm and random headers, with minor differences such as adding prefix std:: to some of the function calls.

• Calls to std::shuffle and std::*_distribution are now grfstd::shuffle and grfstd::*_distribution.

[jtibshirani]

The PR is looking great, the approach is very clean. A couple small comments, then I think it is ready to merge:

• I think the common naming convention is nonstd for something from the standard library that's been copied or modified. This is the namespace for the implementation of 'optional' we copied in, for example. We could rename the grfstd directory to random to distinguish it from optional.
• It would be good to add a README.md to the directory stating how the code was pulled together and why it exists. Important information would include what compiler's standard library was used, and also what modifications were made to the files (I think it is just removing methods related to operator<< as well as uses of _LIBCPP macros?)

[halflearned]

Thanks for the review, @jtibshirani! I'm also pretty happy with how this turned out.

On nonstd: that's a good point, I should have checked what was done for optional.

On the README: will do.

I'm a little tied up today and tomorrow, but by Friday I should have this done.

[halflearned]

Thank for the review, @jtibshirani! It should be ready for a second round whenever you have the time.

[jtibshirani]

Looks good to me!

After this merges, I plan to enable the characterization tests in CI. Having them enabled in CI is nice on its own, and will also serve as a sort of test for this PR.

[erikcs]

Making a note of that:

After #1006 core GRF is tested to produce the same result with three different compilers (latest version), using the same seed and number of threads on

• GCC
• Clang
• MSVC

Using Intel's C++ compiler ICC does not give the exact same results, but close. Evidently its compiler optimizations are more "aggressive", if they are set to -O0 or -O1 the ForestCharacterizationTest matches exactly on the linux machine I tried out ICC 19.0.0.117 on.