Currently http://dlang.org/library/std/algorithm/sorting/partial_sort.html takes a range and an index. That is unnecessarily restricted. One overload of partialSort should be added that accepts TWO ranges and performs the operations considering the first one the left side, and the second one the right side of the same range.
Comment #1 by lt.infiltrator — 2015-12-08T12:08:41Z
Once issue 15421 is fixed, this is a simple matter of
topN(l, r);
sort(l);
Which brings us to the question of: should partialSort(Range, index) be changed to call partialSort(r[0..n], r[n..$]) to reduce duplication or is there a large performance difference in the two topNs?
Comment #2 by andrei — 2015-12-08T14:07:33Z
(In reply to Infiltrator from comment #1)
> Once issue 15421 is fixed, this is a simple matter of
> topN(l, r);
> sort(l);
>
> Which brings us to the question of: should partialSort(Range, index) be
> changed to call partialSort(r[0..n], r[n..$]) to reduce duplication or is
> there a large performance difference in the two topNs?
Affirmative.
Comment #3 by lt.infiltrator — 2015-12-09T08:08:47Z
(In reply to Andrei Alexandrescu from comment #2)
> (In reply to Infiltrator from comment #1)
> > Once issue 15421 is fixed, this is a simple matter of
> > topN(l, r);
> > sort(l);
> >
> > Which brings us to the question of: should partialSort(Range, index) be
> > changed to call partialSort(r[0..n], r[n..$]) to reduce duplication or is
> > there a large performance difference in the two topNs?
>
> Affirmative.
Sorry, do you mean affirmative to how to implement partialSort(Range, Range);
or affirmative to changing partialSort(Range, index) to call the (Range, Range) version;
or affirmative to there being too large of a performance difference between the two versions of topN?
Comment #4 by andrei — 2015-12-09T13:44:17Z
(In reply to Infiltrator from comment #3)
> (In reply to Andrei Alexandrescu from comment #2)
> > (In reply to Infiltrator from comment #1)
> > > Once issue 15421 is fixed, this is a simple matter of
> > > topN(l, r);
> > > sort(l);
> > >
> > > Which brings us to the question of: should partialSort(Range, index) be
> > > changed to call partialSort(r[0..n], r[n..$]) to reduce duplication or is
> > > there a large performance difference in the two topNs?
> >
> > Affirmative.
>
> Sorry, do you mean affirmative to how to implement partialSort(Range, Range);
> or affirmative to changing partialSort(Range, index) to call the (Range,
> Range) version;
> or affirmative to there being too large of a performance difference between
> the two versions of topN?
My bad, I missed the "or". I don't think there's a loss of efficiency if partialSort with index calls partialSort with the two subranges.
Comment #5 by jack — 2016-04-29T14:38:21Z
*** This issue has been marked as a duplicate of issue 14294 ***