1st draft of complete class-based std.random successor

[Joseph Rushton Wakeling]

On Sunday, 23 March 2014 at 10:15:32 UTC, bearophile wrote:
> Is the issue is already fixed in std.random you can close it :-)

Well, your request for a "choice" method is still open ... :-)

> The best thing is to add an efficient choice() function, so no 
> efficiency mistake happens :-)

Sure, I'm simply raising a couple of simple internal 
implementations that could be used for an effective first draft 
of that function.

> So you are saying that those RNGs are already weakly pure and 
> they can't become strongly pure because they take the engine as 
> mutable class reference. And even if you design a very small 
> random engine that can be created every time you call a random 
> generator, the API of all the random functions is not 
> compatible with it. So it's not a simple problem...

I think I need to make some detailed research into how Haskell 
and other functional languages handle randomness before 
commenting here.  What it does seem to me at this stage is that 
while a weakly pure range-based RNG is readily possible (as 
implemented in std.random2.generator now), I'm not sure that the 
range-based approach typical of Phobos plays nicely with strong 
purity where random number generation is concerned.

> A possibility is to also add a less precise (more approximate) 
> but faster function implementation.

Again, this is something I'll look into.  I need to re-read the 
paper on gaussian-distribution algorithms that I linked to 
earlier in this thread, but my recollection is that the 
speed/precision tradeoff is something of a false dichotomy given 
the algorithms out there now; so a good range-based solution 
(which stores internal state) will probably be able to provide 
high-quality normal variates faster than a low-quality, purely 
function-based implementation.

> Are the ddocs produced by std.random2 online somewhere?

Not yet.  I can make that happen :-)