[boost] Re: Random Number Generators

From: Kevlin Henney (Kevlin.Henney_at_[hidden])
Date: 1998-12-12 08:09:42

The only reason I suggested going for the adaptor approach was from a
design flexibility and cohesiveness perspective:

* It would be convenient to be able to take any conforming RNG object and
use it as an iterator without requiring all RNG -- or indeed any generated
sequence -- authors to also implement an iterator protocol.

* Although a class can be implemented to support 2 different protocol sets
(RNG function object _and_ iterator), this might be considered less
cohesive.
* Based on my own experience with RNGs and iterators, there is no problem
modelling an RNG as an iterator. There is an interface cohesiveness issue,
however, in having a class support 2 very different protocol sets --
equally a function object _and_ an iterator.

I will have a look at implementing the layered approach, and see what
everyone thinks.

Kevlin

Beman Dawes <beman_at_[hidden]> on 10/12/98 01:31:43

Please respond to boost_at_[hidden]

To:   boost_at_[hidden]
cc:    (bcc: Kevlin Henney/QA Training Ltd)
Subject:  [boost] Re: Random Number Generators

At 07:08 PM 12/9/98 +0000, Kevlin Henney wrote:

>I am not sure that this is a fair characterisation of the algorithm
used,
>which is a linear feedback shift register which has well known
properties
>as a competent and efficient generator. The generator in question
uses a 32
>bit LSFR to produce bits, and so standard usage is to accumulate the
bits
>as necessary to create an integer of the appropriate size: no
revalidation
>is needed for different types if the underlying bit generation is
sound; it
>is needed if you mess with the LSFR size and composition -- no
intention of
>doing that!
>
>The pseudo-container suggestion in the original work proved a point
about
>generated sequences, but is not essential to the random number
issue. I
>prefer the suggestion that a counting adapter, taking begin iterator
and
>count, would be more appropriate as this has general application.
This is
>definitely worth having.
>
>Core to the original work was the idea of generated sequence as
iterator,
>and I think that is the most valuable thing, ie relationship to
iterator
>requirements, etc.
>
>I do not see that having alternative implementations of a random
number
>generator is necessarily a bad thing, esp as the one I was proposing
had
>different usage properties (ie template parameterisation),
performance
>characteristics and explores a different model consistent with other
parts
>of the standard library.
>
>Maybe a suitable area of convergence would be to separate out some
concerns
>and consider this as three separate layers:
>
>* Random number generation, using a generator function conforming to
std
>requirements.

Yes, particularly the requirements for a random number generating
function object in 25.2.11.

>* An adaptor class, templated on (and initialised by an instance of)
a
>random generator type, that allows a generator to be used as a
forward
>iterator to const.

I am unsure if this separate adapter class is needed.  Greg Colvin
has said in private email that he thinks the RNG class itself can
model an iterator.  That would be simpler if it can be made to work.

>* An adaptor that creates the effect of a pseudo-container by taking
a
>begin iterator and count -- this last is more general purpose.

Yes, that seems would seem to be needed if you want, say, begin() and
end() for 1000 iterators using some specified RNG.

>What do you think?

Give it a try!  Put some code together and post it to this mailing
list to see what people think of it.  The feedback should be
valuable.

--Beman
------------------------------------------------------------------------
Don't lose your email when you move, change jobs, or switch ISP's.
Click here to get free and permanent email from NET_at_DDRESS!
http://ads.egroups.com/click/154/0

Free Web-based e-mail groups -- http://www.eGroups.com

------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com