[boost] Re: Proposal: random number library

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-02-18 10:53:03

From: Jens Maurer <jmaurer_at_[hidden]>
> 
> Beman Dawes wrote:
> 
> Thanks for the comments.
> 
> > *  Is there a reason you didn't specify the interface to meet the
> > RandomNumberGenerator requirements in 25.2.11
> > [lib.alg.random.shuffle] by providing operator()(long) in addition to
> > the Generator (operator()()) requirements?
> 
> Yes.  The UniformRandomNumberGenerator requirements are written so that
> you can plug in any random number generator you find in the literature
> with minimal effort.  For example, implementing L'Ecuyer's combined
> linear congruential generator (from 1988) was just fun.  And these
> generators usually provide a uniform distribution on some integer
> range.
> 
> However, implementing operator()(long n) is more difficult than it
> may seem at first.  The trivial (rng % n) is incorrect if the range
> of the rng is smaller than n, and it is slightly incorrect if the range
> is larger than n because of quantization effects.  That means it is
> a considerable burden for UniformRandomNumberGenerator implementors
> to get operator()(long) correct. Thus, I provided a
> random_number_generator template (whose implementation is still buggy
> as described above) which implemenents the RandomNumberGenerator
> requirements.
> 
> > *  It often seems useful to be able to get the current rng value (via
> > value() and/or a conversion operator) without stepping to the next
> > value.  It saves setting up a work variable just to hang on to the
> > value through a few lines of code.
> 
> Hm... You're right, I did have to set up a temporary variable in a few
> places myself.
> 
> > *  Supplying operator++() seems to me to make the intent of user code
> > clearer:
> > 
> >       some_rng_class rng;
> >       while ( ... )
> >       {
> >          f1(++rng);  // call a function with a new rng value
> >          f2(rng);    // call a function with the current rng value
> >          f2(rng.value());  // some prefer to avoid a conversion
> > operator
> >       }
> 
> There shall never be an implicit conversion operator, that I feel quite
> strongly about.
> 
> We've basically got the choice between three interfaces:
> 
>  (1) The Generator STL requirements, i.e. operator() (only)
>  (2) operator++ / value()
>  (3) Iterator in the STL sense, i.e. operator++ and operator*
> 
> For the basic random number generators (minstd_rand, mt19937 etc.),
> (1) seems to be the most minimal, everything else is a decoration.
> I shall provide decoration classes [TODO].  For the distribution functors
> such as gaussian_distribution, which are intended for use by user
> code, I am unbiased whether to integrate a non-minimal interface such
> as (2) and (3).
> 
> What do the others on this list think?

I've long preferred interface (3).