$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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.
Matthias Troyer