Re: [boost] [random] new threefry random engine

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.