https://github.com/libmir/mir-random

# mir-random
Dlang Random Number Generators

#### Comparison with Phobos
##### Generators
 - `opCall` API instead of range interface is used (similar to C++)
 - No default and copy constructors are allowed for generators.
 - 64-bit Mt19937 initialization is fixed
 - 64-bit Mt19937 is default for 64-bit targets
 - `unpredictableSeed` has not state, returns `ulong`
 - Does not depend on DRuntime (Better C concept)
 - [WIP] additional Xorshift generators

##### Integer uniform generators
[WIP]

##### Real uniform generators
[WIP]

##### Nonuniform generators
[WIP]

Please contact me if you are interesting to contribute!
https://gitter.im/libmir/public

On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
>  - `opCall` API instead of range interface is used (similar to C++)

This seems like a gratuitous departure from common D practice. Random number generators are most naturally modeled in D as infinite ranges. -- Andrei

On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei Alexandrescu wrote:
> On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
>>  - `opCall` API instead of range interface is used (similar to C++)
>
> This seems like a gratuitous departure from common D practice. Random number generators are most naturally modeled in D as infinite ranges. -- Andrei

Yes, I think this is avoiding the existing problems with RNGs and ranges rather than solving them.

I don't blame anyone for _wanting_ to avoid them; they are nasty, subtle issues that seem to keep getting more complex the more one looks at them (for example, after my DConf talk last year, I realized that there were a whole set of other potential complications related to how ranges typically treat laziness).  But I think they can be solved, and should be.

OTOH, there's no reason per se why there should not be an `opCall` for random number generators along the lines of,

    UIntType opCall()
    {
        this.popFront();
        return this.front;
    }

... just to provide options to the user.  (BTW, note the order there, which touches on the issues related to what lazy evaluation means not just for RNGs but for any non-deterministic IO.)

On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei Alexandrescu wrote:
> On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
>>  - `opCall` API instead of range interface is used (similar to C++)
>
> This seems like a gratuitous departure from common D practice. Random number generators are most naturally modeled in D as infinite ranges. -- Andrei

I'm pretty sure everyone *wants* it to be a range, but it turns out it's a difficult design space. Lot's of nasty trade-offs that can be (and have been) argued back and forth depending on your priorities.

Perhaps you have an insight that has been missed that can make a good rng range without causing less than optimal performance or statistically unsafe default behaviour?

IIRC you think people are making too much fuss about the statistically safe default behaviour, but it would be interesting to hear a more expanded version of that view.

On Tuesday, 22 November 2016 at 06:31:45 UTC, Ilya Yaroshenko wrote:
> ##### Integer uniform generators
> [WIP]
>
> ##### Real uniform generators
> [WIP]
>
> ##### Nonuniform generators
> [WIP]

As we discussed in relation to Seb's project, I think this is a problematic conceptualization of the best way to structure functionality related to randomness.

An arguably better way (as outlined in the C++11 standard) is to think in terms of:

  * random _generators_, i.e. sources of uniformly distributed random bits:

    - random _engines_ (seedable, pseudo-random algorithms)

    - random _devices_ (non-deterministic sources of uniformly distributed bits)

  * random _distributions_, which transform uniformly-distributed random bits
    into variates with some other type and distribution

    - note _this includes uniformly-distributed integers_!

    - also uniformly-distributed floats, enums, etc.

    - and also non-uniform distributions

  * random _algorithms_, i.e. algorithms in the sense of std.random, but where
    their popFront() includes random decision-making

    - randomCover, randomSample, etc.

The point of the above breakdown is that it gives a nice and clear separation of concerns that allows for easily replaceable components.  Separating out stuff just by the ultimate result you want (integers vs. floats, uniform vs. non-uniform, etc.) isn't helpful in that way.

On Tuesday, 22 November 2016 at 06:31:45 UTC, Ilya Yaroshenko wrote:
>  - 64-bit Mt19937 is default for 64-bit targets

This means that seemingly identical code will produce different results depending on whether it's compiled for 64-bit or 32-bit.  Is that really worth it, when anyone who cares about the difference between 32-bit vs. 64-bit random words is quite capable of specifying the RNG they want to use and not just relying on the default?

Having a different default RNG would make sense for targets where there are serious performance issues at stake (e.g. minimal memory available for RNG state) but just for the sake of 32- vs. 64-bit Mersenne Twister seems an unnecessary complication.

These days it's debatable whether Mersenne Twister of _any_ word size is the optimal choice for a default RNG, so if the default is going to be changed, it might as well be to something significantly better (rather than worrying about numbers of bits).

On 11/22/16 7:44 PM, Joseph Rushton Wakeling wrote:
> These days it's debatable whether Mersenne Twister of _any_ word size is
> the optimal choice for a default RNG

Interesting. Could you please add a couple of links about that? -- Andrei

On 11/22/16 7:36 PM, Joseph Rushton Wakeling wrote:
>
>   * random _generators_, i.e. sources of uniformly distributed random bits:
>
>     - random _engines_ (seedable, pseudo-random algorithms)
>
>     - random _devices_ (non-deterministic sources of uniformly
> distributed bits)
>
>   * random _distributions_, which transform uniformly-distributed random
> bits
>     into variates with some other type and distribution
>
>     - note _this includes uniformly-distributed integers_!
>
>     - also uniformly-distributed floats, enums, etc.
>
>     - and also non-uniform distributions
>
>   * random _algorithms_, i.e. algorithms in the sense of std.random, but
> where
>     their popFront() includes random decision-making
>
>     - randomCover, randomSample, etc.

Yah, I think that would be nice. -- Andrei

On 11/22/16 7:30 PM, John Colvin wrote:
> On Tuesday, 22 November 2016 at 23:55:01 UTC, Andrei Alexandrescu wrote:
>> On 11/22/16 1:31 AM, Ilya Yaroshenko wrote:
>>>  - `opCall` API instead of range interface is used (similar to C++)
>>
>> This seems like a gratuitous departure from common D practice. Random
>> number generators are most naturally modeled in D as infinite ranges.
>> -- Andrei
>
> I'm pretty sure everyone *wants* it to be a range, but it turns out it's
> a difficult design space. Lot's of nasty trade-offs that can be (and
> have been) argued back and forth depending on your priorities.

The proposed design has disabled copy ctor and uses opCall() for a new element. That seems to be a difference without a distinction from an input range that has disabled copy ctor and offers the input range primitives.

> Perhaps you have an insight that has been missed that can make a good
> rng range without causing less than optimal performance or statistically
> unsafe default behaviour?

We should add a reference RNG that transforms any other RNG into an input range that shares the actual RNG.

> IIRC you think people are making too much fuss about the statistically
> safe default behaviour, but it would be interesting to hear a more
> expanded version of that view.

I'm unclear on what that statistically unsafe default behavior is - my understanding is it has to do with RNGs being inadvertently copied. It would be great to formalize that in a well-explained issue.


Andrei

On Wednesday, 23 November 2016 at 01:28:11 UTC, Andrei Alexandrescu wrote:
> On 11/22/16 7:44 PM, Joseph Rushton Wakeling wrote:
>> These days it's debatable whether Mersenne Twister of _any_ word size is
>> the optimal choice for a default RNG
>
> Interesting. Could you please add a couple of links about that? -- Andrei

http://www.pcg-random.org/other-rngs.html

;-)