From: Jens Maurer (jmaurer_at_[hidden])
Date: 1999-11-08 16:53:58
> 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 non-zero 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 floating-point 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 compile-time only, so you
would want to use templates and save all run-time 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.
> // STL "Generator" and "RandomNumberGenerator" conformance
> // 0 <= i <= 2^32-1
> 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.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk