[Issue 7067] std.random.RandomSample and RandomCover are poorly designed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7067

--- Comment #23 from Joseph Rushton Wakeling <joseph.wakeling at webdrake.net> ---
@Martin @Jens: sorry for radio silence on this.  It's a busy period, and I
recently moved to a new apartment where I still don't have home internet.

> I don't think that sharing rng state among multiple consumers is a good idea.
> Of course it looks like you want random numbers and shouldn't care about the
> order, but often fixed seeds are used to get a reproducible pseudo-random
> range.
>
> When you share such a RNG as in
>    auto rng = Random(fixedSeed);
>    assert(!equal(randomCover(a, rng), randomCover(a, rng)));
> the sequences depends on the implementation of equal and randomCover.

Yes, a case like this obviously creates complications.  But I don't think
subtleties like this should prevent a user from instantiating one RNG instance
and using it with multiple consumers.  The "default" case (where no RNG
instance is passed) already employs a common RNG instance between different
consumers; I'd rather have consistency of behaviour whether an RNG is
explicitly provided or not.

Of course, we can advise associating different RNG instances with different
consumers (or making sure that a consumer does its work before associating an
RNG with a new consumer), but that's different from compelling the user to
follow this pattern.

Note also that one-RNG-per-consumer really doesn't scale to e.g. a simulation
where you are generating thousands or millions of random samples.  The risk of
the different RNG seeds generating correlated sequences seems greater than the
risks associated with using one RNG underlying all sample instances.

> Also we'd set a bad precedent by making one of std's ranges a ref type. Ref ranges have a lot of subtleties and aren't that well tested with std.algorithm.

I agree there are a lot of subtleties, but my feeling is that we need to
embrace and explore those in order to identify what the best way forward is for
RNGs.

--