Ranges and random numbers -- again

[Joseph Rushton Wakeling]

On 06/17/2013 09:00 PM, H. S. Teoh wrote:
> I understand your reasons for choosing this rule, but I feel a bit
> uneasy about it. Under this rule, RNGs would produce their entire random
> sequence just by accessing .front multiple times, which violates the
> standard range behaviour of .front not changing until you call
> popFront().

In the general case, I will make some remarks on this in that next email I
talked about.  Suffice to say that I don't think that simply calling front() 3
times should produce 3 different results.  The point is that an iteration across
the entire thing should produce different results.

In the specific case of pseudo-random number generators, I would say that (odd
though it might seem) I don't consider them to be random ranges.  There is
nothing random about their popFront() statements!  They are deterministic
sequences just as much as std.range.iota, std.range.sequence or
std.range.recurrence.

> Is it possible to arrange it so that the ctors behave as though
> popFront() were called at the end? (I say "as though" because there are
> some cases for which this shouldn't actually happen, like when there's a
> finite permutation sequence involved.)

In brief, the solution I came to with RandomSample was to define a boolean
variable called _first which was set to true in the constructor.  Then inside
front() there would be a check for _first, and if it was true, an initial value
for front would be determined, and _first would be set to false.

If _first was false, then front would just return its present value.

However, this has some problems, which I'll discuss in the next email.