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
Are the ddocs produced by std.random2 online somewhere?
Not yet. I can make that happen :-)