Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at