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
