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

Subject: Re: [boost] [random] new threefry random engine
From: John Salmon (john_at_[hidden])
Date: 2014-05-02 10:30:09

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