[boost] Re: Boost Random Number Library Framework Proposal

From: Jens Maurer (jmaurer_at_[hidden])
Date: 1999-11-08 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 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.

class random_number:
>         // 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.)

Jens Maurer