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.
