Ranges and random numbers -- again

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Mon Jun 17 15:18:36 PDT 2013


On 06/17/2013 09:36 PM, monarch_dodra wrote:
> Good analysis but (sorry) I think you are on the wrong track.
> 
> One of the major problems in std.random is that the ranges use value semantics.
> This means they are *saved* whenever they are copied, as opposed to just
> referenced. This creates the problems you have mentioned, and even more.

I agree that the fact that pseudo-random number generators use value semantics
is a serious problem, and I was thinking of our previous discussions in
preparing these remarks.

However, I'll stress again for the avoidance of doubt that when referring to
"random ranges" I was not referring to pseudo-random number generators, but to
ranges that _call_ random-number generators (real or pseudo) inside popFront().

> I have tried to fix it before:
> http://forum.dlang.org/thread/oiczxzkzxketxitncghl@forum.dlang.org
> FWI, I gave up on the project, because it was too complex for me to handle an
> entire module. But there were no reasons for it to not work.

I remember your work and was sad to see that it was not accepted -- actually one
reason to start this discussion was to try and push awareness back to your
contributions :-)

> A random range should be viewed (IMO) as nothing more than a range that "was"
> (conceptually) simply filled with random numbers. Calling front on the same
> range twice in a row *should* produce the same result: No call to popFront => no
> change to the range. If it did change, it'd be a blatant violation of the range
> concept. It also means you can't have safe/nothrow/pure/const "front".

Completely agree, and I don't think this is in contradiction with what I've
proposed.  My proposed "rule" might be better stated to clarify this.

> Being able to *save* a random range (which your proposal would prevent) can have
> useful applications too. It means you can iterate on the same random number
> sequence several times, lazily, without having to store the results in a buffer.

I agree, but there are broader issues to do with .save and ranges that call
random number generators in popFront().  If they are calling rndGen() or any
other "global" random number generator, then it's impossible for them to
reproduce the same sequence over and over.

> The problems you are trying to fix can (imo) can be better fixed with the
> reference approach.

On the contrary, consider the SimpleRandomRange -- or RandomSample -- with a
specified RNG that has reference semantics.  You'll get a different sequence
each time you iterate over it, and .save will not enable you to reproduce the
sequence.

I'd be happy to see a way in which one _could_ reproduce the sequence with
.save, but it would have to be statistically reliable.  (That is, if I pass it a
given random number generator, then the results of the sequence would have to be
uncorrelated with other subsequent calls to that generator in other parts of the
program.)



More information about the Digitalmars-d mailing list