A simple solution for randomness copy problem

[Joseph Rushton Wakeling via Digitalmars-d]

On Tuesday, 29 November 2016 at 08:50:52 UTC, Ilya Yaroshenko 
wrote:
> The solution is to add a `hot` flag that indicates that 
> precomputed random values can be used and reset this flag in 
> copy constructor. It works without performance issues for the 
> Vitter's algorithm and Normal sampling (of course if you don't 
> copy the struct for each call).

Oh, nice.  This feels like a bit of a "facepalm" moment as in, 
"How did no one think of that before?" :-P

It could be a heavy performance hit for larger state variables 
(e.g. a Ziggurat), but on that note ...

> Both Vitter's random sample algorithm and normal distribution 
> needs this flag or analog anyway (at least in my 
> implementations).

I'm not sure that it's so important for distributions.  Unlike 
the general case of random algorithms (which likely need to be 
created multiple times in inner program loops), distributions are 
much more likely to be created at a relatively high level and 
then _used_ multiple times in an inner loop.

That means that in principle, distributions could be treated in 
the same way as RNGs, i.e. just ban copying by value and expect 
them to be passed around by ref or by pointer.

Of course, including the `hot` flag could offer best of both 
worlds: if you pass around by ref then you avoid needing to 
recreate the internal state, if you pass around by value then the 
internal state is regenerated for statistical safety.

I'll try this out in detail with the Phobos std.random stuff and 
see how it plays.  Thank you _very_ much for focusing on this 
problem.

>         if (isSaturatedRandomEngine!G)

Question on your terminology here: while saturated makes sense, 
is it really your intention to restrict things to random 
_engines_ (i.e. pseudo-random algorithms)?  Surely it should also 
be possible for this functionality to work with random devices?