isUniformRNG

[Nick Sabalausky via Digitalmars-d]

On 5/23/2014 3:04 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> Hi Nick,
>
> Short reply because I think things are converging pretty well
> decision-wise :-)
>
>>> because crypto RNGs' .popFront() is of necessity going to be non-pure.)
>>>
>>
>> To make sure I understand (it seems my understanding of D's pure isn't
>> quite as
>> strong as I'd thought): It cannot be pure *because* of the static
>> internal
>> state, right?
>
> The main issue is because your popFront will be relying on external
> sources of entropy which I presume to be non-deterministic (otherwise,
> what entropy are they adding?).  That's what makes purity impossible.
>
> As we've discussed, you could avoid having the static variables, but as
> the function is going to be impure anyway, they shouldn't be avoided
> over the purity issue.
>

Oh, right. For some reason I was thinking "front", not "popFront". My bad.

>> I think I may have missed that particular discussion (I've only been
>> catching
>> the livestreams of certain talks). Recap?
>
> Andrei's opening keynote seemed pretty clear that we need a space in the
> standard library where people can experiment freely.  He called it
> std.experimental but I suspect the name will be something different :-)
>

Didn't we already have exp.* for that? (Or something like that.)

That's one talk I sadly missed. Anxiously awaiting the rerun on YouTube.

> Well, what I'm inclined to do is to submit my Phobos package as an
> experimental module (probably call it exp.random or something like
> that).  I can and probably will do that in the very near future.
>
> I think that you should similarly feel unrestricted, but maybe give it a
> day or two post-Dconf to see what the actual plan is about the
> experimental repo.
>

Ok.

> By the way, what are your thoughts on having a std.random.crypto module
> versus a general std.crypto module that includes crypto RNGs and other
> crypto functionality?  I'd been considering a std.random.crypto but I'm
> starting to incline towards the view that std.random and crypto should
> be kept deliberately separate.

Well, I don't think crypto RNGs should be put together with non-RNG 
crypto stuff like SHA, etc. (Unless maybe it's all under a 
"std.crypto.*" package...but then you still have weird questions like 
"Does MD5 go in std.digest.md or std.crypto.digest.md? What about 
SHA-1?" So still maybe kinda hairy.)

As for whether crypto RNGs should be together with non-crypto RNGs, I 
dunno. I can't really say I'd have much objection either way. I suppose 
there is general preference in D at this point to break up phobos 
modules wherever reasonable, so I guess something like this might 
generally be preferred:

std/random/package.d
std/random/deterministic.d
std/random/crypto.d

But I don't have any strong opinions on the matter. I'd say just pick 
something, run with it, and see if any bikeshedding erupts ;)