isUniformRNG

[Nick Sabalausky via Digitalmars-d]

On 5/8/2014 5:29 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On 08/05/14 19:18, Nick Sabalausky via Digitalmars-d wrote:
>> Some good looking stuff in there. The separation is a nice
>> improvement, and
>> having a "shuffle" is something we could certainly use.
>
> Thanks! :-)
>
> There is already a shuffle function in the existing std.random, but it's
> called randomShuffle:
> http://dlang.org/phobos/std_random.html#.randomShuffle
>

How'd I either miss or forget that?! ;)

>> About avoiding problems from accidentally duplicating internal state,
>> I'm not
>> sure that changing to classes is really necessary for that. I
>> addressed it in
>> HashDRBG by simply making the internal state static. (Oops, or at
>> least I meant
>> to...fixing now...). The various InputRange instantiations (for the
>> different
>> possible elemement types) all draw from the same source
>> (HashDRBGStream), so
>> this should work out pretty well. I'd imagine the existing std.random
>> algos
>> could do something similar.
>
> 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.

 > While many
> applications wouldn't notice the difference, it's a pretty major breach
> of encapsulation (and purity).

AIUI an RNG is impure by definition. (Well, unless you consider the 
internal state to be part of the input, but I'd say *that* view breaks 
encapsulation.)

I'm also unconvinced that it breaks encapsulation anyway. If anything, I 
think it's better encapsulated since separate instances *won't* behave 
like they're under "quantum entanglement". It forces separate instances 
to stay separate.

It *is* a fairly strange situation though. Unlike most encapsulation 
units, the whole point of an RNG is to be *inconsistent* rather than 
consistent. So that kinda turns everything on its ear.

>
> On a related note -- I like your concept of a random stream.  I think it
> may be useful to adapt as part of the way in which std.random2.device
> works.  I need to compare to other Phobos stream code -- isn't Steven
> Schweighoffer working on up-to-date stream functionality as part of
> std.io ... ?

Yea, when I wrote it I figured on proposing an optional stream-like 
interface for std.random. The Hash_DRBG algorithm is inherently based 
around the idea that each generated number can be arbitrary-length (not 
only that - generating ex. two 8-byte values with Hash_DRGB is 
fundamentally different from generating eight 2-byte values, and 
produces different results). And the OS-specific entropy generators are 
basically streams, too (on both Win and Posix, you request any number of 
bytes of randomness).

So that was just a natural way to implement it. But it did strike me as 
being generally useful, so I'm glad that you agree.

You're right though, the current state of Phobos streams is kind of a 
stumbling block. Naturally it'd be best to use the new stream interface, 
but since that isn't in place, that's an issue. I don't know what the 
state of the rewrite is. Been awhile since I've heard anything about it.

I figure, at the very least, we could just make the stream interfaces 
for RNGs private. Then we can open it up whenever we finally do have a 
new std.stream to conform to.

Or we could do an OutputRange instead...but the recent discussion on 
those makes me a bit hesitant to do so. And I definitely don't wanna 
perform the contortions to invert it into a non-coroutine-like InputRange.

Hmm, yea, I'm more and more liking the "keep it private for now, and 
then see what happens" approach...unfortunately... :/