[boost] Re: Proposal: random number library

From: Beman Dawes (beman_at_[hidden])
Date: 2000-02-22 11:11:42

At 02:26 AM 2/22/00 +0100, Jens Maurer wrote:
>
>Beman Dawes wrote:
>> >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*
>
>> In larger classes it is usually a serious mistake to try to
provide
>> two distinct (let alone three) interfaces.
>
>I've implemented a generator_iterator decorator and extended
>random_demo.cpp to show the usage.  However, the iterator
>interface isn't that useful anyway, because I haven't found
>an STL algorithm you could sensibly use with this kind of
>iterator: algorithms usually want some "past-the-end" iterator
>to say "STOP" to them, which we simply cannot provide for random
>numbers in the general case (that's why they're random, after all).
>
>Does anyone have convincing arguments why (3) fits more nicely
>in some existing framework such as STL?
>
>Is using the generator_iterator decorator too much a nuisance for
>the casual user? Personally, I'm still very happy with saying
>int tmp = rng(); if(tmp < 1 || tmp > 5) do_this(); else do_that();
>Using explicit function-call syntax (albeit on a function object)
>shows to the user that potentially voluminous things are going on
>behind the scenes. Consider random_device as an example. However,
>I recognize "++rng" as some lightweight operation, such as
>incrementing an integer or pointer or advancing an iterator,
>which are all just a few clock cycles.  In short, providing an
>operator++ violates the principle of least surprise for me.

I guess it is personal taste; operator++ seems much clearer to me
than operator().  But you are doing the work, so in the end it is
your call.  I can certainly live with only operator(), and I would
expect most others can also live with it.

>The next update will move random_device to a fresh directory and
>out of random.hpp, unless anybody objects.

Moving random_device to a separate header with separate documentation
sounds like a good idea to me, but I would prefer not to add a fresh
directory.  Look at the current utility and integer libraries as
examples of grouping related headers/docs together.  I want to avoid
having too many small directories, particularly when they are closely
related.

By the way, people have asked in the past that uploads of multiple
files to the vault include a .zip file of all the other files to make
it easy to download as a package.  See the Info-Zip site
http://www.cdrom.com/pub/infozip/ if you need a zip program for your
platform.

--Beman