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

Subject: Re: [boost] [Random] design of the random library
From: John Phillips (phillips_at_[hidden])
Date: 2008-11-14 20:26:19

Ares Lagae wrote:
> 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/
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> 

   You raise a number of issues here, and have some good points. Let me 
give you a partial explanation. The boost.random library predates the 
TR1 spec, and was an important inspiration for it. Many of the 
differences are based on attempts to fix issues in boost.random. The 
idea that you find TR1 an improvement implies that effort was at least 
partially successful. If you want the TR1 interface, one choice is the 
TR1 library (also in boost). Another is a vendor provided version.

   That said, my understanding is that the C++0x version is modified 
compared to TR1, as well. I haven't looked closely enough to be able to 
list the changes for you. At some point, the boost.random library may 
need to be changed if the conclusion is that the new version is better.

                        John Phillips