Berlin D Meetup Feb 2015

[Ben Palmer via Digitalmars-d-announce]

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.

Thanks,
Ben.