Boost logo

Boost :

Subject: Re: [boost] [random] new threefry random engine
From: Thijs van den Berg (thijs_at_[hidden])
Date: 2014-05-02 10:44:13

On 02 May 2014, at 16:30, John Salmon <john_at_[hidden]> wrote:

> On Fri, May 2, 2014 at 8:32 AM, Peter Dimov <lists_at_[hidden]> wrote:
>> Thijs van den Berg wrote:
>>> In that case it’s best to use a random engine adaptor.
>>> counter_based_engine< Threefry<2,unsigned> > eng;
>>> uniform_real_distribution<float> zero_one(0., 1.);
>>> eng.seed(thread_id);
>>> for(int i=0; i<n; ++i)
>>> {
>>> out[i] = in[i]*zero_one( eng );
>>> }
>> The adaptor needs to be in the loop; you don't have a thread_id outside it.
>> uniform_real_distribution<float> zero_one(0., 1.);
>> #pragma omp parallel for
>> for( int i=0; i<n; ++i )
>> {
>> counter_based_engine< Threefry<2,unsigned> > eng;
>> eng.seed( i );
>> out[i] = in[i]*zero_one( eng );
>> }
>> In principle, this works with any engine, not just a counter-based one, as
>> long as creating and seeding is quick and consecutive seeds result in
>> random first output.
> Yes. But Boost's documentation advises that in general, these
> requirements are *not* met:
> <snip
> Pseudo-random number generators should not be constructed
> (initialized) frequently during program execution, for two
> reasons. First, initialization requires full initialization of the
> internal state of the generator. Thus, generators with a lot of
> internal state (see below) are costly to initialize. Second,
> initialization always requires some value used as a "seed" for the
> generated sequence. It is usually difficult to obtain several good
> seed values...
> </snip>
> This is very good advice because as far as I know, none of the
> existing engines satisfy all the requirements: small state,
> quick-to-initialize, quick-to-run and high-quality, statistically
> independent results when seeded consecutively.
> Counter-based RNGs are specifically designed to meet these
> requirements. State ranges from 8 to 32 bytes. They generate 8 to 32
> random bytes at a time at rates of 2-4 cycles-per-byte.
> Initialization time is negligible compared to generation.
> Output passes TestU01.
> John Salmon
I think there isn’t any discussion about counter based random engines being a good idea. What needs to be made clear is the benefits of having a random function concept next to a random engine concept. When would a user have clear benefit of using a random function directly instead of a random engine that implements the same algorithm? The concept and benefit need to be made clear IMO. So far I’ve hear about 4 different types of random functions. The challenge is to capture them all in a single concepts.

Boost list run by bdawes at, gregod at, cpdaniel at, john at