|Posted by Joseph Rushton Wakeling|
in reply to bearophile
Posted in reply to bearophile
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 :-)