Mir Random [WIP]

[Ilya Yaroshenko via Digitalmars-d]

On Wednesday, 23 November 2016 at 16:54:44 UTC, Andrei 
Alexandrescu wrote:
> On 11/23/2016 10:52 AM, Ilya Yaroshenko wrote:
>> I started with Engines as basis. The library will be very 
>> different
>> comparing with Phobos and _any_ other RNG libraries in terms 
>> of floating
>> point generation quality. All FP generation I have seen are not
>> saturated (amount of possible unique FP values are very small 
>> comparing
>> with ideal situation because of IEEE arithmetic). I have not 
>> found the
>> idea described by others, so it may be an article in the 
>> future.
>
> Is this a design matter, or an implementation matter? Could you 
> implement the superior FP generation on the existing std.random 
> API? To not be able to vs. to not want to is a different 
> matter; I have an appreciation for each, but we need to 
> clarify. -- Andrei

Floating point generation are implementation matter. 
Distributions and algorithms are design matter.

Assume your are building a modification Mod_X ~ 1 / X + X for a 
distribution. This is how it will look in Mir Random:

-------------------------

struct Mod(D)
   if(isRandomVariable!D && isFloatingPoint!(ReturnType!D))
{
     D irv;
     alias irv this;
     ReturnType!D opCall(G)(ref G gen)
         if(isSURBG!D)
     {
         ReturnType!D x1 = void;
         do x1 = irv(gen);
         while(x1 == 0);
         ReturnType!D x2 = irv(gen);
         
/////////////////////////////////////////////////////////////////////////
         /////////////////   X1 and X2 are independent! 
///////////////
         
////////////////////////////////////////////////////////////////////////
         return 1 / x1 + x2;
     }
}

unittest
{
     auto gen = Xorshift(1);
     auto rv = Mod!GammaRandomVariable(...);
     auto x = rv(gen); /// generator is never copied by value.
}

-------------------------

How it can be done with Range interface instead of opCall?
Please note that users would use Distributions, not Engines.

So, Range API requirements are:

1. Engine must not have implicit copy semantic: it is not correct 
for RNGs and has performance issues. They also should not be 
copied explicitly in this example.

2. Do not use Engine's pointers in RandomVariable, because 
RandomVariables can be passed easily outside of function: they 
are just a small tuples of params.

3. Do not use classes because of BetterC and performance issues.

4. Engines must have Range interface

5. RandomVariables (both Mod and an underlaying) must have Range 
interface.

I don't think Range API for random variables can be done easily 
and without performance or security issues.

Thanks,
Ilya