Mir Random [WIP]

[Ilya Yaroshenko via Digitalmars-d]

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

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). In additional, when 
you need to write algorithms or distributions opCall is much more 
convenient than range API. In additions, users would not use 
Engine API in 99% cases: they will just want to call `rand` or 
`uniform`, or other distribution.

I am sure that almost any library should have low level API that 
is fits to its implementation first. Addition API levels also may 
be added. Current Phobos evolution is generic degradation: more 
generic and "universal" code hide more uncovered bugs in the 
code. The std.range is good example of degradation, it has a lot 
of API and implementation  bugs.

### Example of API+implementation bug:

#### Bug: RNGs has min and max params (hello C++). But, they are 
not used when an uniform integer number is generated : 
`uniform!ulong` / `uniform!ulong(0, 100)`.

#### Solution: In Mir Rundom any RNGs must generate all 
8/16/32/64 bits uniformly. It is RNG problem how to do it.

I will not fill this bug as well another dozen std.random bugs 
because the module should be rewritten anyway and I am working on 
it. std.random is a collection of bugs from C/C++ libraries 
extended with D generic idioms. For example, there is no reason 
in 64 bit Xorshift. It is 32 bit by design. Furthermore, 64 
expansion of 32 bit algorithms must be proved theoretically 
before we allow it for end users. 64 bit analogs are exists, but 
they have another implementations. Phobos degrades because we add 
a lot of generic specializations and small utilities without 
understanding use cases. Phobos really follows stupid idealistic 
idea: more generic is better, more API is better, more universal 
algorithms is better. The problems is that Phobos/DRuntime is 
soup where all (because its "universality") interacts with 
everything.