I thought I would give a brief summary of the last meetup. Joseph Wakeling gave a presentation entitled “Random number generation in Phobos and beyond”. It was a great talk and we had some interesting discussions afterwards.

The talk began by mentioning some naive ways of generating random numbers and some of the negative consequences this can cause. Joseph then mentioned other methods of generating random numbers including big tables of random numbers, physical randomness, and deterministic methods (pseudo-random).

Pseudo-random number generators (RNGs) use a state variable and a transition function that maps from the current state to the next state and this sounds like a good match for a forward range. Currently in Phobos all RNGs are implemented as ForwardRange structs. Other ranges such as randomCover and randomSample wrap the Phobos RNGs.

Wrapping the RNGs can cause problems as structs are passed by value. This means that if the same RNG is used in subsequent calls to say randomCover then the same sequence of random numbers will be produced by each range.

A simple solution to this would be make random ranges classes. This can also cause problems but with memory management (we want to avoid lots of small alloc and free events). It also does not address problems with functions that make bad assumptions about their arguments.

If we can solve these problems then there are several different avenues to push forward with new RNG wrapper functionality. There are also other opportunities for looking at random number generation.

After the talk there was some discussion on a number of points including:

Testing RNGs. The unittests in std.random don't (and can't) provide tests of randomness. There are existing RNG tests in linux. It would be good to get a good randomness test suite in D.

Does the c++ standard library have the same problems? Possibly, there was some certainty that the boost documentation has some reference to the same problems.

Is this a general problem with forward ranges? Could there be something missing from the range interface or perhaps it would be better to have a distinct range type for random numbers.

There was then a discussion of the various types of hardware RNGs. Martin Novak mentioned “haveged” a C program that can generate large numbers of random numbers. It generates randomness based on variations in code execution time on a processor.


Reply via email to