Mir Random [WIP]

[Joseph Rushton Wakeling via Digitalmars-d]

On Wednesday, 23 November 2016 at 11:14:38 UTC, Ilya Yaroshenko 
wrote:
> 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.

Yes, but as described, `opCall` can easily be created as a 
composition of `popFront` and `front` for these convenience 
purposes.

> We don't restrict. It is 1 minute to write an Range wrapper.

If all you have is `opCall` then the range wrapper is less 
efficient than it need be.

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

Yes, most uses of RNGs in std.random involve calling `front` and 
then `popFront()` (although it would probably be better the other 
way round).  But it's readily possible to imagine range-based 
use-cases for random distributions along the lines of,

     myRNG.normalDistribution(0.0, 5.0).filter!(a => a > 
0).somethingElse.take(20);

But what I'd say more broadly is that of what I've seen so far, 
mir.random is conflating too many breaking changes without giving 
thought for their impact (for example, converting the 
`isUniformRNG` check to rely on a UDA is IMO problematic; I can 
file a GitHub issue explaining the reasons for this).  Allowing 
for the wider goals of the exercise, it could be worth giving 
some thought to which of these breakages is really needed to 
support your use-cases, and which can be avoided.