Boost logo

Boost :

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


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

> On Fri, May 2, 2014 at 1:26 AM, Steven Watanabe <watanabesj_at_[hidden]>wrote:
>
>> AMDG
>>
>> On 04/27/2014 05:39 AM, Mathias Gaunard wrote:
>>>
>>> With a single, stateless generator, everything is much simpler. One
>>> seed, one generator, completely reproducible results regardless of
>>> scheduling. The interface i want to have is this:
>>>
>>> #pragma omp for
>>> for(int i=0; i<n; ++i)
>>> {
>>> out[i] = in[i] * random_value(i);
>>> }
>>>
>>
>> The proposed RandomFunction doesn't quite work this
>> way. It produces random numbers in blocks. (For
>> instance, the threefry engine that started this thread,
>> uses a 256-bit block size.)
>>
>
> Yes. But with C++11 initializer lists, random_value is a one-liner:
>
> unsigned random_value(unsigned i){
> return Threefry<2, unsigned>()({i})[0];
> }
>
> Without initializer lists, you would need another line for a declaration
> of a domain_type.
>
> Alternatively, you may prefer to let a distribution do the rescaling for
> you:
>
> Threefry<2,unsigned> prf;
> uniform_real_distribution<float> zero_one(0., 1.);
> #omp
> for(int i=0; i<n; ++i)
> {
> out[i] = in[i]*zero_one( counter_based_urng(prf, {i}) );
> }
>
> John Salmon

The zero_one distribution can do any amount of call to the urng. E.g. the current normal_distribribution uses ziggurat with rejection sampling. The previous version uses Box Muller and consumed an even amount of random numbers. The only way I can see "counter_based_urng(prf, {i})” to be able to generate an arbitrary number of random values is when it has it’s own internal counter. 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 );
}


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk