On Thursday, 20 September 2012 at 11:10:43 UTC, Jonathan M Davis
wrote:
[SNIP]
- Jonathan M Davis
#1
Hey, I've been working on this (locally): I've made all the PRNGs
reference ranges. It actually works perfectly. I took the "ensure
initialized" route, as you suggested. I was able to take an
approach that moved little code, so there is a clean distinction
between the old "Payload", which was not touched (much), and the
wrappers. The advantage is that the diff is very clean.
I was able to do this without adding or removing any
functionality. Great!
Regarding the cost of "is initialized", I think I found a very
good work around. I'll show it in a pull.
#2
Johannes Pfau: When asking for a generator, by default you get a
reference prng. This is the _safe_ approach.
If somebody *really* wants to, they can always declare a
PRNGPayload on the stack, but I advise against that as:
*Passing it by value could generate duplicate sequences
*Passing it by value (for certain PRNGs) can be prohibitively
expansive.
But the option is there.
#3
The only thing I'm having an issue with is "save". IMO, it is
exceptionally dangerous to have a PRNG be a ForwardRange: It
should only be saved if you have a damn good reason to do so. You
can still "dup" if you want (manually) (if you think that is
smart), but I don't think it should answer true to
"isForwardRange".
You just don't know what an algorithm will do under the hood if
it finds out the range is saveable. In particular, save can be
non-trivial and expensive...
I think if somebody really wants to be able to access some random
numbers more than once, they are just as well off doing:
Type[] randomNumbers = myPRNG.take(50).array();
The advantage here is that at no point to you ever risk having
duplicate numbers. (Take advances the reference range generator.
QUESTION:
If I (were to) deprecate "save", how would that work with the
range traits type? If a range has "save", but it is deprecated,
does it answer true to isForwardRange?
