Re: [boost] random number library review

From: Jens Maurer (jmaurer_at_[hidden])
Date: 2000-06-07 16:35:06

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;

I shall add an explicit statement to the documentation.

> 2) copying issues; passing rng-s as parameters
[...]
> 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).

>From the "random-concepts.html" documentation:

>>> Classes which model a pseudo-random number generator
>>> may also model the CopyConstructible and Assignable concepts.
>>> However, note that the sequences of the original and the copy
>>> are strongly correlated (in fact, they are identical), which may make
>>> them unsuitable for some problem domains. Thus, copying
>>> pseudo-random number generators is discouraged; they should always
>>> be passed by (non-const) reference. 

I am willing to disable copying and assignment for random number
generators, if this is the consensus of the group.

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

Ok.  The plan is to have an enum 
enum random_distribution { random_uniform_int, [...] random_normal }
and an appropriate "static const" member within each distribution.

Or do we want a traits class (more extensible than a member) like
this (similar to std::iterator_traits<>)?

template<class T>
class random_traits {
  static const random_distribution = ...
};

> Adding appropriate information that can be checked at compile time would be
> a great plus.

I think it is a good principle to make all template parameters
available as members within the class template to facilitate further
processing.  Only mersenne_twister seems to be lacking in this
respect.  For others, please complain with specifics.

For other compile-time checking, we should see what we really
need.  I want to see applications first before I'm adding more
elaborate compile-time functionality.

> 4) why static const in linear_congruential?
> 
> Simply, I don't like the static modifiers here. Why do you need them?

For potential compile-time computations with the LCG parameters.

>   As a
> result you can not have two linear congruential generators with different
> parameters in the same program 

Yes, you can.  LCGs with different parameters have different types
(note the template value parameters), thus the "static" members are
actually disjoint.

Jens Maurer