On Friday, 9 May 2014 at 00:43:10 UTC, Nick Sabalausky wrote:
On 5/8/2014 5:29 PM, Joseph Rushton Wakeling via Digitalmars-d
wrote:
That seems a problematic fix for me -- doesn't it mean that
there can
only ever be one instance of any individual RNG?
There can technically be multiple "instances", but yea, they're
all effectively tied together. However, I'm leaning towards the
belief that's "correct behavior" for a RNG. It's *definitely*
correct for a crypto RNG - you certainly wouldn't want two
crypto RNGs ever generating the same sequence, not even
deliberately. That would defeat the whole point of a crypto RNG.
As for ordinary non-crypto RNGs, I honestly can't imaging any
purpose for reliably generating the same values other than
"playing back" a previous sequence. But if that's what you
want, then IMO it's better to record the sequence of emitted
values, or even record/replay the higher-level decisions which
the randomness was used to influence.
For randomness, record/replay is just less fiddly and
error-prone than reliably regenerating values from an algorithm
that intentionally tries to imitate non-predictability. One
slip-up while regenerating the sequence (example: trying to
replay from the same seed on a RNG that has since had a bug
fixed, or on a different architecture which the RNG wasn't
well-tested on) and then the inaccuracies just cascade. Plus
this way you can swap in a non-deterministic RNG and everything
will still work. Or more easily skip back/ahead.
I'm just not seeing a legitimate use-case for multiple states
of the same RNG engine (at least on the same thread) that
wouldn't be better served by different approach.
I strongly disagree here. If a user has explicitly requested a
PRNG, they should be able to rely on its most basic property,
being deterministic.
