[boost] Re: Proposal: random number library

From: Beman Dawes (beman_at_[hidden])
Date: 2000-02-18 15:06:20

At 04:04 PM 2/18/00 +0100, Jens Maurer wrote:

>> *  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.

Sorry, I missed random_number_generator.  So it is really a
documentation issue; you might want to include your comments above.

>...
>
>There shall never be an implicit conversion operator, that I feel
quite
>strongly about.

No problem.  value() is fine.

>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).

In larger classes it is usually a serious mistake to try to provide
two distinct (let alone three) interfaces.  But in this case each
interface only has one or two members, and all have their uses, so I
see considerable benefit and little downside to providing more than a
minimal set.  Personally I would go with all of them, except maybe
choose between value() and operator* (assuming the semantics are the
same).

>I only tested with gcc 2.95.2 and gcc-very-recent-experimental
>on Linux.
>Thanks for testing with more compilers.

I keep meaning to set up a script to run boost code against multiple
compilers.  It's probably a good time to start.  Now where is that
book on Perl I keep meaning to read...

>> *  The hyphens in file names make me slightly nervous.
>
>I'll fix the .cpp files [Done], I hope they're no problem for the
HTML
>files?

Not a problem, AFAIK. 

>> *  I tried to compile random-test.cpp.  Microsoft VC++ 6.0 sp3
>> doesn't allow in class initializers, so gets errors on the
following.
>>  Maybe some VC++ experts can suggest an easy way around.
>
>>   static const bool has_fixed_range = true;
>>   static const result_type min_value = 0;
>>   static const result_type max_value =
static_cast<result_type>(-1); 
>
>We can replace this with non-compile-time constants, i.e. implement
>member functions min() and max() and have an enum has_fixed_range =
false.
>This gets a x2 performance hit on some distribution functors, but I
think
>that's ok for a non-conforming compiler. [Done]
>
>Can we please have a #define BOOST_NO_INCLASS_MEMBER_INITIALIZER
>in <boost/config.hpp> to indicate violation of std:9.4.2/4?

Done.  Except I spelled it BOOST_NO_INCLASS_MEMBER_INITIALIZATION.

>> *  Metrowerks CodeWarrior said this conversion was illegal:
>> 
>>   static const result_type max_value =
static_cast<result_type>(-1);
>
>Do we have any boost-compatible method which gives a compile-time
constant
>for the maximum of some integer type?
std::numeric_limits<type>::max()
>is obviously not up to the task. [Ugly work-around in place.]

Valentin Bonnard had a solution. He was going to provide a header
called <boost/integer_traits.hpp> containing a template class
boost::integer_traits, derived from std::numeric_limits,adding
const_min and const_max members.

We really should get going on this.  Anyone care to volunteer?

>Can we please have a #define BOOST_STDINT_H_HAS_UINT64_T in
><boost/config.hpp>?
>Note that, for 64bit machines, this may be different from
>"HAS_ULONGLONG".

I haven't added BOOST_STDINT_H_HAS_UINT64_T, pending resolution of Ed
Brey's comment (in a later message). 

Cheers,

--Beman