AMDG On 06/13/2014 09:17 AM, John Salmon wrote:
On Tue, May 27, 2014 at 2:48 PM, John Salmon
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