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

Subject: Re: [boost] [random] new threefry random engine
From: Thijs (M.A.) van den Berg (thijs_at_[hidden])
Date: 2014-04-22 12:40:17

>> 
>> On 04/21/2014 02:28 PM, John Salmon wrote:
>>> 

> A better approach is to devise a trivial, application-specific mapping
> of time (iteration number) plus some stable aspect your logical
> elements (e.g., atom id) into unique 128-bit inputs.  You can now
> obtain the random values you need, wherever and whenever you need them
> simply by generating a unique 128-bit input and calling the
> RandomFunction.  There is no space overhead.  

I think this above is one of the core argument you make. This would imply the need 
1) a function/functor that initializes the random output buffer with (e.g.) 128bit of input -possibly assembled from bits of memory and signals here and there-. For C++ random engines this could be a counter functor, but it could also be a unique id of a machine/thread/core with a timestamp.
2) the "randomFunction" with a possible state (like the algorithmic specific encryption key in threefry) that scrambles the output-buffer in-place.

Most of the benefits you see revolve around not owning memory.

I can easily factor out the scrambling function, but I think they would need to be functors holding function specific state for them to be a concept that can be combined with other concepts. For me having a generic interface has more value than having detailed control. So the big challenge would be to define good concepts.

I'm still hoping that designing the new concepts (which are imo difficult to get accepted and I don't have time and passion for that) gets decoupled from delivering a new random engine(s) (clear and manageable deliverable).