Mir Random [WIP]

Ilya Yaroshenko via Digitalmars-d digitalmars-d at puremagic.com
Wed Nov 23 03:14:38 PST 2016


On Wednesday, 23 November 2016 at 10:57:04 UTC, Joseph Rushton 
Wakeling wrote:
> 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?

For example, Mir Random basic utilities (more low level then 
distributions):
https://github.com/libmir/mir-random/blob/master/source/random/package.d

Also you can explore std.random code. opCall would almost always 
more convenient to use.

>>  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.

We don't restrict. It is 1 minute to write an Range wrapper. This 
wrapper can be added to the library, if we found a real world use 
case. Again, I have not seen a real world algorithm, which looks 
better with Range API for generators. RandomSample can be created 
without Range API, and it would look more convenient then it is 
now. I think that Range API is bad and useless overengineering 
for RNGs.


More information about the Digitalmars-d mailing list