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
