On Wednesday, 23 November 2016 at 05:58:47 UTC, Ilya Yaroshenko
wrote:
It is safe low level architecture without performance and API
issues. It prevents users to do stupid things implicitly (like
copying RNGs). A hight level range interface can be added in
the future (it will hold a _pointer_ to an RNG).
Note that if you want to do this, it's convenient to still
preserve a separation between popping the RNG state versus
getting the current variate. Otherwise, the range interface will
wind up having to separately cache the variate value, which is
wasteful.
Something like this:
struct MyRNG
{
void popFront() { /* update internal state */ }
UIntType front() @property { return /* whatever part of
internal state */; }
UIntType opCall()
{
this.popFront();
return this.front;
}
}
(The above is basically just the input range API less the `empty`
property, and the `front` and `popFront()` are arguably a
lower-level API than `opCall`.)
In additional, when you need to write algorithms or
distributions opCall is much more convenient than range API.
Can you give some examples of what you mean here?
In additions, users would not use Engine API in 99% cases:
they will just want to call `rand` or `uniform`, or other
distribution.
I don't think that's necessarily true, but in any case, we
shouldn't restrict the use-cases of the 1% unless we have to.
