
Boost : 
From: Jens Maurer (jmaurer_at_[hidden])
Date: 19991108 16:53:58
jeetsukumaran_at_[hidden] wrote:
> 1. There will be an abstract base class (protocol class) that shall
> define the interface through which all random number requests by client
> code are made. I've included a proposal of such a base class, called
> "random_number" below.
This is a bad idea. Most simulations need lots of random numbers,
so we should avoid virtual functions, because they prevent inlining
and have a nonzero call overhead anyway.
> The scheme, in fact, seems to approach the
> orthogonal decomposition of the STL  we can vary PRNG algorithms
> (through the generator classes we pass to the templates), random number
> distributions (through the template implentations) and return
> values/ranges (through the particular interface function invoked)
> independently of each other.
So we basically have two dimensions:
 PRNG algorithm (produces uniform random number distribution)
 random number distribution (uniform, gaussian)
The return value range is a parameter for the distribution: A gaussian
distribution always has range [inf, +inf], but you can vary the average
and variance. On the other hand, a uniform distribution can be mapped
to any finite range, be it [0..1] or [1..1]. Moreover, certain
distributions have integer results.
I am not sure whether the basic PRNG algorithms should return some
uniformly distributed integer in [0..max] or a real [0..1]. Most
algorithms can produce some fixed number of random bits in each
iteration, and I am not sure how to map these most efficiently and
flexibly to the output data type. A floatingpoint divide might be
too expensive compared to just filling the mantissa with random bits.
Probably we have to employ a template parameter for the output data
type and for the mapping to it.
> Furthermore, we have achieved dynamic as well as static polymorphism.
> A function that requires random numbers can have a reference argument
> to "random_number."
Most of the time, you will want to do that compiletime only, so you
would want to use templates and save all runtime overhead.
> (2) Also, the PRNG objects are seeded once during construction. In its
> present incarnation, there is no room for resetting the PRNG objects,
> or reseeding them with different seeds. This can be handled by adding
> the appropriate methods in the protocol base class, but it will require
> further specifications to be fulfilled by our PRNG classes  e.g. the
> definition of a function reseed(n) or reset().
If we used templates, a "seed" function would only be required if
explicitly called by the client.
class random_number:
> // STL "Generator" and "RandomNumberGenerator" conformance
>
> // 0 <= i <= 2^321
> virtual uinteger_t operator()(void) = 0;
>
> // 0 <= i < n
> virtual uinteger_t operator()(uinteger_t n) = 0;
This does not allow STL classes to use operator() polymorphically,
because STL does not use pointer indirection on the random number
generators it requires (see std::random_shuffle() etc.)
Jens Maurer
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk