Subject: Re: [boost] [random] new threefry random engine
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2014-06-13 13:21:46
On 06/13/2014 09:17 AM, John Salmon wrote:
> On Tue, May 27, 2014 at 2:48 PM, John Salmon <john_at_[hidden]> wrote:
>> Can we agree that counter_based_engine, implemented roughly along these
>> lines is a worthwhile addition to Boost.Random? If so, what's the way
The main thing I need is documentation as doxygen+quickbook.
>> Should I start a 'feature branch', i.e.,
>> to make it easier to ultimately merge into boost?
Sure. The headers aren't a big deal, since it's
trivial for me to copy files, but the documentation
does need to be integrated into the Boost.Random
- threefry primary template: BOOST_STATIC_ASSERT( N==2 || N==4 )
Just don't provide the primary template.
- counter_traits.hpp: comments about SeedSeq and birthday paradox.
I'm not sure that this is actually true. It's obviously the
case that mapping from 4 integers to 3 is going to have this
problem, but there is no way around this. If the destination
range is larger, then I really hope the outputs would always
be distinct for distinct inputs of the same size. I haven't
analyzed the algorithm and I have no idea where it comes from,
but if it doesn't have this property, then some outputs would
be totally unreachable. (Of course, the performance issues
of seed_seq still apply.)
- Making detail::counter_traits a template parameter of
counter_based_engine adds boost::random::detail to the
set of associated namespaces.
- make_counter and 64-bit: Boost.Random generally requires
32-bit sequences. (This is inherited from std::seed_seq)
Handling different widths is a lot of complication for
- The iterator seed and constructors of counter_based_engine
are overloaded based on the constness of the first argument.
Don't do this. It's far to error-prone.
- I'm unconvinced of the value of restart. I'm thinking that
we can get the same result by allowing multiprecision
integers with discard.
>> Second ping, Can anybody hear me?
> It's been more than two weeks, with no response to the above, nor to a
> resend on June 3. I understand that people are busy. But note that I'm
> asking what *I* should do, not for someone else to do something. In any
> case, a reply along the lines of "I'm busy and won't be able to get into
> this until approximately <DATE>, but until then, you could help by doing
> XXX" would be appreciated.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk