On Mon, Jun 17, 2013 at 08:32:14PM +0100, Joseph Rushton Wakeling wrote:
> Hello all,
> 
> I think my last post on this topic may have been too convoluted, so here's another go.  The goal here is to try and derive some well-defined strategies for designing ranges that make use of random number generators.
> 
> The purpose of this first email is to justify what I think should be the first basic rule of random ranges [that is, ranges where popFront() makes use of random or pseudo-random numbers to generate the new value of front()].  That rule is:
> 
>     **************************************************************************
>     * Reading multiple times from the start of the same random range, should *
>     * produce different (and statistically independent) results each time.   *
>     **************************************************************************
[...]

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().

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.)


T

-- 
Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy

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.