From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2002-02-05 15:59:42
Matthias Troyer wrote:
> The problem we face at the moment is that the arguments to the seed(...)
> function and to the non-default constructor are dependent on the
I agree this is a non-orthogonality in the current interface that
makes it difficult to change generators by means of a single
"typedef" or equivalent.
> One solution would be to always require a seed(uint32_t ). However the
> problem there is that for generators like the LCG many integers are bad
> seed values, and the good/bad values differ from generator to generator.
> Also, a lagged Fibonacci generator, or a Mersenne Twister (MT) needs a
> seed block instead of a single integer.
You could initialize a MT by means of a seed LCG, which itself
is seeded by a uint32_t.
> There are however solutions to this problem, as implemented e.g. in the
> SPRNG library (http://sprng.cs.fsu.edu/). These solutions take a
> "sequence number", a nonnegative integer, and convert it into a good
> seed for lagged Fibonacci generator. Similar algorithms can be
> for the MT, or also for LCGs. This makes it possible to write more
If algorithms that derive provably good seeds from a sequence number
are indeed available for a wide variety of random number generators,
the proposed additional interface appears to be reasonable, and even
better than the current state-based interfaces.
> Since I do not want to change the semantics of seed(uint32_t) where
> it is avaiable, I propose to add the following members to the generators:
> sequence(uint32_t n) ; // seeds the generator with the n-th good seed
> static const uint32_t max_sequence; // n can take all values
I'm slightly concerned about using "uint32_t" in a generic
interface. History has proven time and again that having a
fixed-sized bit width in some interface gets you into trouble in
the long run. (16 bit wchar_t anyone?)
Do we need constructors that take a sequence number instead of a
state-based seed as well?
(Please make sure to include "random" in all subject lines pertaining
to the topic. Thanks.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk