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 :-)
