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.
