From: Matthias Troyer (troyer_at_[hidden])
Date: 2000-06-07 06:49:08
Csaba Szepesvari wrote:
> 1) seed initialization; rng "independence"
> In linear_congruential the current default initialization initializes the
> seed to the constant 1. This might lead to unexpected problems for some
> users who think (naively?) that it's ok to create two or more rng of the
> same type, without *explicitly* telling that they are different; e.g.
> typedef boost::minstd_rand base_generator_type;
> base_generator_type generator; // has default constructor!
> boost::uniform_01<base_generator_type> uni1(generator); // rng no 1
> boost::uniform_01<base_generator_type> uni2(generator); // rng no 2
> for(int i = 0; i < 10; i++) std::cout << uni1() << uni2() << '\n';
> // oops: numbers are the same
> We need a (sensible/non-sensible, but documented) mechanism for dealing with
> rng independence.
> [In my projects, I'm using a static counter, incremented by each
> construction by default; this yields reproducibility given that the order of
> constructions are not changed and some independence.]
I do not know if that is a good idea. Often the quality of a RNG depends
sensitively on the quality of the seed value. Thus just incrementing the seed
by 1 might not be a good idea. I prefer to seed my RNGs manually. I believe
that a warning is all that is needed as most users will be aware of the
fact that identical seeds give identical sequences.
Also, I would like to have reproducability, which becomes harder when
the program transparantly increments a counter without me knowing what
seed it actually used.
> 3) checking conformance
> When an rng is passed along, the client might want to have a means for
> checking if it received an appropriate one (appropriate distribution).
> Adding appropriate information that can be checked at compile time would be
> a great plus.
I agree. It would be nice to have some compile time checkable flag
to test the type of distribution.
> 4) why static const in linear_congruential?
> Simply, I don't like the static modifiers here. Why do you need them? As a
> result you can not have two linear congruential generators with different
> parameters in the same program and the users might be unaware of this, which
> might cause serious trouble.
I do not see the problem with that. As far as I understand the code this
is no problem, since the LCG is templated on those parameters anyways.
Thus there should be no problem with having two different LCGs.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk