Re: [boost] [Random] design of the random library

Subject: Re: [boost] [Random] design of the random library
From: Ares Lagae (ares.lagae_at_[hidden])
Date: 2008-11-14 18:06:41

After some time with the Boost.Random and TR1 random library I found that
most of the magic happens in variate_generator. I now understand how the
library works, but I still have several issues with the design.

I am not sure if all of these issues are correct, but I would appreciate if
people involved in Boost.Random could have a look at this.

* Regarding the implementation of variate_generator, TR1 specifies " ...
Otherwise, if the value for engine_value_type::result_-  type is true and
the value for Distribution::input_type is false, then the numbers in seng
are divided by engine().max() - engine().min() + 1 to obtain the numbers in
se. ... " Is this correct? What happens when engine().min() is not zero? At
first sight, the numbers in se are not in [0,1), and the distribution
templates will not handle this case correctly. Boost.Random uses uniform_01
and does not seem to follow the TR1.

* Random distribution class templates specify an input_type, that determines
wether variate_generator will provide them with a floating point  [0,1) or
integer min max distribution. However, this is not specified in TR1! How
can the user know this? If variate_generator is not used, a naive user can
and will expect that normal_distribution works with linear_congruential,
but it does not. I think that input_type should disappear, and that random
distribution class templates should handle all kinds of engines. At least
there should be a static assert that will prevent a Random distribution
class template to work with en engine if their input_type and result_type
differ.

* Random distribution class templates specify an input_type, that determines
wether variate_generator will provide them with a floating point  [0,1) or
integer min max distribution. I think that input_type should be
implementation defined, since this is an implementation detail. For
example, the best way to construct a normal distribution might be using
e.g. Box Muller from a floating point [0,1) distribution today, but that
might change to an integer distribution in the future. (Probably not, but
you get the point.)

* variate_generator<some_engine, uniform_01> results in a strange situation.
The numbers are transformed twice to [0,1). A first time by
variate_generator and a second time by uniform_01. Off course, the second
operation is not needed and should be avoided.

* When the template argument for the parameter Engine of the class template
variate_generator is of the form U (not U& or U*), the it is passed by
value, which can be expensive. It would probably help to define a
parameter_type in ptr_helper that determines how the parameter is passed
(U& in that case).

* Naming is sloppy. For example the normal_distribution has parameters mean
and sigma. The second one is the name of the symbol that is often used to
describe standard deviation. The symbol that is often used for mean is mu.
So I think it should be mu and sigma, or even better, mean and
standard_deviation. In general I think that parameters should be named
according to their meaning, and not the mathematical symbol.

I have come across more strange issues, but these are the most important
ones at first sight.

Comments are appreciated.

--
Ares Lagae, Ph.D.
Computer Graphics Research Group, Katholieke Universiteit Leuven
http://www.cs.kuleuven.be/~ares/