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