std.random2

[Joseph Rushton Wakeling]

On 01/08/2013 10:05 PM, monarch_dodra wrote:
> I'd argue PRNG's should even be forward ranges. For one, the actual saving would
> be duplicating the PRNG payload itself (very costly). Further more, it would
> mean the danger of duplicate sequence still exist: a lot of algorithms, such a
> "fill", start by saving their input, and then iterating on the copy...

That's a good point; I'd not really thought about the implications of .save in 
that respect.

> I'm all for them having "dup" though.

Got to be able to have the option to save the random state to stop the player 
reloading to get a different random outcome ... :-)

> @jmdavis was against making them input ranges, saying input ranges just aren't
> useful compared to a forward range. I think that:
> 1. A PRNG naturally models input, and not forward.
> 2. Algorithms that operate on actual random sequenes shouldn't rely on the PRNG
> to be saveable anyways: A *true* RNG simply cannot provide save.

I would say that it's not useful if a PRNG makes it easy for you to shoot 
yourself in the foot with flawed statistics.

Now, that said, the problem with something like a take(N) approach is that some 
algorithms might not take a predictable number of random variates.  RandomSample 
is a good example of that, although fortunately in this case the ForwardRange 
characteristics are not required.