Mir Random [WIP]

Ilya Yaroshenko via Digitalmars-d digitalmars-d at puremagic.com
Wed Nov 23 04:18:28 PST 2016


On Wednesday, 23 November 2016 at 11:44:44 UTC, Joseph Rushton 
Wakeling wrote:
> 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.

Inlining will solve this problem with data duplication (if any) 
for most real world cases.

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

Yes, please file a GitHub issue.


More information about the Digitalmars-d mailing list