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