On Wednesday, 30 November 2016 at 12:28:28 UTC, Ilya Yaroshenko
wrote:
Of course they can work with random devices. It looks strange
to me to have explicit API difference between engines and
devices. A random devices can be marked as random engines or we
can add a simple generic adaptor
On Wednesday, 30 November 2016 at 11:29:25 UTC, Joseph Rushton
Wakeling wrote:
On Tuesday, 29 November 2016 at 08:50:52 UTC, Ilya Yaroshenko
if (isSaturatedRandomEngine!G)
Question on your terminology here: while saturated makes sense,
is it really your intention to restrict things
One minor nitpick - please avoid calling postblit constructor a
"copy constructor", it tends to mislead developers with C++
origins into expecting copy constructor they are used to - and
disappointment when it proves to not be the case.
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
Hello,
The problem is that a structure for a random algorithm or a
random variable may holds its own precomputed random state, which
is not correct to copy.
From [1] by Joseph Rushton Wakeling:
Essentially the sampling algorithm carries out its own little
internal pseudo-random process
