Re: [boost] [random] Determining interest in Pseudo-Random Functions and Counter Based Random Number Generators

Subject: Re: [boost] [random] Determining interest in Pseudo-Random Functions and Counter Based Random Number Generators
From: John Salmon (john_at_[hidden])
Date: 2012-01-27 10:09:24

On Thu, Jan 26, 2012 at 6:21 PM, Steven Watanabe <watanabesj_at_[hidden]>wrote:

> AMDG
>
> On 01/26/2012 09:29 AM, thijs_at_[hidden] wrote:
> >
> >> Our work is definitely complementary to TRNG.  We go beyond TRNG by
> arguing
> >> that if you use pseudo-random functions (which we call counter-based
> PRNGs
> >> in the paper), in lieu of conventional PRNGs, then things like 'skip'
> and
> >> 'jump' and 'jump2' become moot.  You simply don't need them.  On the
> other
> >> hand, if you have pseudo-random functions, then it's easy to implement
> >> skip() and jump() and jump2() for the benefit of applications that are
> >> already coded to a TRNG-like APIl.  In fact, I'll probably do that in a
> >> future release of the Random123 library.
> >>
>
> FWIW, the C++ standard library uses void discard(long long);
>

Yes.  There's already a discard() method in counter_based_engine in my
library.
I was addressing the issue raised by TRNG that discard() by itself doesn't
seem to meet the needs of parallel Monte Carlo.  The point is debatable, but
worthy of consideration.  The TRNG library proposes
to add split(), jump() and jump2() to the "Parallel Random Number Engine"
model
to meet the needs of parallel Monte Carlo.  I was pointing out that
pseudo-random
functions could be adapted to provide those methods as well.

>
> >> Still, I would be pleased if our work became part of boost, and that
> boost
> >> wouuld be enhanced by its inclusion, so I'm still interested in finding
> a
> >> way to fit Random123 into boost.
> >>
>
> The issue that I see is that the stateless interface
> doesn't interact well with the distribution concepts
> and I see no easy way to make it work, since the
> distributions don't necessarily use a 1-to-1 transformation
> on the output of the engine.
>

Please see the counter_based_urng<> and counter_based_engine<> adapter
classes in the library.  They allow one to use existing distributions.  For
example,

#include <boost/random/counter_based_urng.hpp>
#include <boost/random/philox.hpp>
#include <boost/random/uniform_int_distribution.hpp>
#include <iostream>

int main(int argc, char **argv){
    typedef boost::random::philox<4, uint32_t> Prf;
    Prf::key_type k={{}};
    Prf::domain_type c={{}};
    // initialize k and c with application-specific, job-specific
    // or thread-specific values, e.g.,
    // k[0] = thread_id;
    // k[1] = seed;
    // ctr[0] = timestamp;
    // ctr[1] = stocksymbol_id;
    boost::random::counter_based_urng<Prf> rng(Prf(k), c);
    boost::random::uniform_int_distribution<int> six(1,6);

    for(int i=0; i<10; ++i){
        std::cout << six(rng) << "\n";
    }
    return 0;
}

> > At first look it would be nice if this would indeed become part of
> boost. As a boost user I would vote for inclusion if there was a vote.
> >
>
> >From my point of view, I definitely support the addition
> of new engines that model the existing concepts.  For
> the stateless interface, the interaction with distributions
> /must/ be resolved first.
>

To the best of my knowledge,

counter_based_engine<philox<4, uint32_t>>

is a new engine that exactly models existing concepts.  We could stop there,
but I think it's much more interesting and valuable to go beyond the
existing concepts.

John Salmon

> In Christ,
> Steven Watanabe
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>