Boost.Random iterator interface revisited

From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2001-08-31 16:25:11

Michael Stevens uses Boost.Random for some interesting work.
He's found a bug in the copy semantics of normal_distribution,
which I have just fixed.  Thanks, Michael!

What's more interesting is that his application seems to require
random numbers from one of Boost.Random's distributions with a
different parameter value for each random number obtained.  That
means creating a fresh distribution function object for each random
number.  Since distribution function objects are just holding the
distribution parameters and a reference to the underlying source of
random numbers, this is actually cheap.

Except for one thing:  When a distribution function object is
initialized, it also initializes the iterator interface.  Remember,
the random distributions in Boost.Random provide both a Generator
(null-ary function) interface and an InputIterator interface.
The latter was added by explicit and rather strong requests from
several people during the review.

Since you can call operator*() on a freshly incarnated InputIterator
as many times as you like (without calling operator++ in between),
there must be a "cache" to hold the last value.  I could either
check every time in operator*() whether the cache was empty, or
just assume that a value was present in operator*() and (re-)fill
the cache with a fresh value when operator++() or the constructor
is called.  That also saves a "bool" member to indicate whether the
cache is full or not, because the cache is always full.

Coming back to the original issue, this design penalizes those
who construct lots of distribution function objects in a tight
loop.  When I accepted the InputIterator interface, I didn't
envision that this may actually happen.  Note that you can
always put an InputIterator interface on top of a Generator
by means of Boost.IteratorAdaptors.

I'd like to know from those who're using Boost.Random whether
they care for the InputIterator interface and I'd like to know
from those who requested the InputIterator interface during
the review whether, after more than a year of experience,
they're strongly in favor of keeping it.

(I've updated the relevant section in the documentation to mark
the InputIterator interface as "deprecated" as a preliminary
measure.)

Jens Maurer