isUniformRNG

[via Digitalmars-d]

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.