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
>> the Generator (operator()()) requirements?
>Yes. The UniformRandomNumberGenerator requirements are written so
>you can plug in any random number generator you find in the
>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
>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
>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
>as described above) which implemenents the RandomNumberGenerator
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
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
>such as gaussian_distribution, which are intended for use by user
>code, I am unbiased whether to integrate a non-minimal interface
>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
>I only tested with gcc 2.95.2 and gcc-very-recent-experimental
>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
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
>> 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 =
>We can replace this with non-compile-time constants, i.e. implement
>member functions min() and max() and have an enum has_fixed_range =
>This gets a x2 performance hit on some distribution functors, but I
>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 =
>Do we have any boost-compatible method which gives a compile-time
>for the maximum of some integer type?
>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
>Note that, for 64bit machines, this may be different from
I haven't added BOOST_STDINT_H_HAS_UINT64_T, pending resolution of Ed
Brey's comment (in a later message).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk