random number library review

From: Csaba Szepesvari (szepes_at_[hidden])
Date: 2000-06-07 06:42:21

Hi All,

Maybe it's a bit late, but I have a few comments re the organization,
content of the random number library; sorry..

1) seed initialization; rng "independence"
2) copying issues; passing rng-s as parameters
3) checking conformance
4) why static const in linear_congruential?

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

2) copying issues; passing rng-s as parameters

The independence issue reappears in this topic; consider the following:
// appropriate typedef for rng
void f( rng r )
{
  cout << r() << endl;
}
void main()
{
  rng r;
  f( r );
  cout << r() << endl;
}

As a result the same number will be printed twice.
You might advice users not doing that (I'd do that), but this needs
explicitly noted in the documentation (maybe it's already there, I could not
find it).

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.

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'm sorry for being short, but I hope that my comments will help in some
respect.

Cheers,

  Csaba