mir.random - my GSoC project

[Joseph Rushton Wakeling via Digitalmars-d]

On Saturday, 23 April 2016 at 14:17:19 UTC, Seb wrote:
> I am very proud to be selected as a GSoC stipend for the D 
> foundation.

Congratulations, Seb!

> This project is about adding non-uniform random generators to 
> mir and hopefully eventually to Phobos.

This is a very welcome contribution.  Thank you for stepping up 
to provide it.

You obviously already have a very good handle on the literature 
related to RNG algorithms.  What I'd advise, though, is that you 
also familiarize yourself with the problematic issues related to 
how random number generation relates to D's range framework.

The broader scope of the problem is that both random number 
generators and random algorithms (i.e. algorithms whose popFront 
includes a call to an RNG; e.g. randomSample or randomCover) face 
a number of problems:

   * if they are not accessed via reference, there are lots of
     ways in which unintended correlations can result

       - one suggestion has been to simply disable copy-by-
         value and force them to be passed by ref or pointer,
         but in my experience that places some nasty limits
         on how readily they can be integrated into e.g. UFCS
         chains of range functionality

       - another option is to implement them as reference
         types; however, this creates some challenges w.r.t.
         memory allocation and the cost of creating multiple
         instances of e.g. a random algorithm in the inner
         loops of a program

   * if pseudo-RNGs are implemented as forward ranges, then
     again, many unintended correlations can be generated,
     in this case because library functionality will freely
     use the .save method to copy range state

       - this is simpler to address; just make all RNGs
         and random algorithms input ranges, and implement
         (say) a 'dup' method for pseudo-RNGs that the
         programmer can call when they're really sure they
         want to duplicate RNG state

   * more an aesthetic issue than a practical one, but note
     that typical range design (where the initial state of
     the .front property is determined upon construction)
     maybe sits a little oddly with random ranges, where
     the values ought ideally to be _truly_ lazy in their
     generation

Some of this is touched on in my DConf talk from last year:
https://www.youtube.com/watch?v=QdMdH7WX2ew

(... which says something about the relative busyness of my time 
since then, that I haven't been able to make much progress on it 
...)

Note that I'm not suggesting you need to find a solution to the 
above issues (although it would be cool if you did:-), but just 
to be aware of them in order to understand how to offer good 
guidance on the usage of the functionality you develop.

> As mentioned mir is quite young, so contributions are very 
> welcome.

Minor aside: I think that was an odd choice of project name, 
given it was already the name of a very well known free software 
project addressing completely different interests ;-)

> PS: I will also be at dconf in Berlin, so maybe we can have a 
> chat there :)

Great, looking forward to it. :-)

Good luck & best wishes,

     -- Joe