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
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
After the talk there was some discussion on a number of points
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.