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
> http://www.boost.org/doc/libs/1_55_0/doc/html/boost_random/reference.html#boost_random.reference.generators
>>
> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk