[Issue 7067] std.random.RandomSample and RandomCover are poorly designed
via Digitalmars-d-bugs
digitalmars-d-bugs at puremagic.com
Mon Mar 2 14:40:58 PST 2015
https://issues.dlang.org/show_bug.cgi?id=7067
--- Comment #21 from Martin Nowak <code at dawg.eu> ---
(In reply to Joseph Rushton Wakeling from comment #20)
> I guess what I don't like about this solution is that it requires the user
> to take responsibility for generating the RNG (or wrapper-of-RNG) as a
> reference type, when that ought to be the default behaviour. But OTOH we
> could take advantage of the fact that RNG structs are templated, and rework
> their convenience aliases, e.g.:
>
> alias Mt19937 = RefCounted!(MersenneTwisterEngine!(uint, 32LU, 624LU,
> 397LU, 31LU, 2567483615u, 11LU, 7LU, 2636928640u, 15LU, 4022730752u, 18LU))
>
> ... which would still leave the underlying struct available for use by
> someone who really wants to use it directly in that form.
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.
Would be cleaner to use 2 RNGs with independent state here, so the fact that a
shared state requires to be explicit is a good thing. 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.
--
More information about the Digitalmars-d-bugs
mailing list