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

Subject: Re: [boost] [random] new threefry random engine
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2014-06-13 13:21:46

AMDG

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
>> forward?
>>

The main thing I need is documentation as doxygen+quickbook.

>> Should I start a 'feature branch', i.e.,
>> https://svn.boost.org/trac/boost/wiki/StartModMaint#Startworkonanewfeature
>> 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
docs.

- 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.
> 

In Christ,
Steven Watanabe