opIndex, opSlice, length for joiner?
Maverick Chardet via Digitalmars-d
digitalmars-d at puremagic.com
Thu Jan 21 14:22:54 PST 2016
On Thursday, 21 January 2016 at 01:22:43 UTC, Andrei Alexandrescu
wrote:
>
> Thanks for askin. Consider chain(), which currently DOES offer
> random access if its constituents to. In that case, the number
> of ranges chained is a compile-time constant dictated by the
> source code being compiled; no data dependency.
>
> In contrast, the performance of joiner()'s proposed primitives
> would be dependent on the data. For your simplest example,
> length would be linear in the number of ranges. One way to
> improve on that would be to compute length upon the first call
> and then memoize (and update) it. There is a risk it could go
> out of sync if someone changes the ranges involved
> surreptitiously.
>
> One good thing to do here would be to specialize
> joiner().walkLength. Then people writing r.walkLength would
> benefit from the quicker specialized version.
>
> For indexed access, things get a fair amount more complicated.
> You can't afford linear time, so you need some serious data
> structure to ensure good performance there. That seems to take
> joiner() in a design space that makes it less attractive;
> currently it's a simple spec with a somewhat straightforward
> implementation.
>
>
> Andrei
Thank you for your remarks!
I just finished to implement the specialized version of
walkLength (this was a great idea), I just have to write a few
comments and clever unittests before the PR, I may send it later
today or tomorrow!
Just a question: is it possible for a range to be considered
infinite and at the same time have a length? I suppose that if it
is possible, such a range would be ill-formed...
I'm asking because for my specialized version to compile in the
case where there is no separator, I require
hasLength!(ElementType!RoR) (otherwise the specialization is
useless), and I'm wondering wether testing for
!isInfinite!(ElementType!RoR) for the version with no "upTo"
parameter is useful or not at all...
Maverick Chardet
More information about the Digitalmars-d
mailing list