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.
