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

On Tue, May 27, 2014 at 2:48 PM, John Salmon wrote:

On Mon, May 5, 2014 at 9:10 AM, John Salmon wrote:

...

On Fri, May 2, 2014 at 11:43 AM, Steven Watanabe wrote:

...

AMDG

On 04/29/2014 10:00 AM, John Salmon wrote:

...

I've dusted off the code I wrote a couple of years ago and republished

it,

...

now on github:

https://github.com/DEShawResearch/Random123-Boost

For this to be included in Boost.Random, it must be released under the Boost Software License.

Done! The version at the above URL is now under the Boost Software License.

While waiting for permission to change the license, I had some useful conversations with Thijs off-line, resulting in some changes to the implementation. I won't quote the whole README again, but it now starts this way, which I hope is much more to Steven's liking:

<snip README.md> CBENG's are fully generic "Random Number Engines", satisfying all the requirements of C++11 and Boost Engines. They can be used anywhere that other engines can be used. When used with the provided "pseudo random functions", threefry and philox, CBENGs are "crush resistant", i.e., they pass the very demanding suite of 'SmallCrush' 'Crush' and 'BigCrush' tests in the TestU01 package. CBENGs based on threefry and philox are fast (comparable to the mersenne twister) and small (requiring only a few words of state).

CBENGs are excellent random number engines in any context, but two features make them especially well suited to parallel computations:

- a fast (constant time) restart() member function that allows the caller to manage a huge number of distinct streams. - a fast (constant time) discard() member function.

The restart() member is unique to CBENGs, while discard() follows standard semantics (but very few engines permit constant-time implementations).

</snip>

There is only one counter_based_engine, as Steven requested elsewhere in the thread.

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?

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?

Cheers,

John Salmon

Any thoughts on this?

John