Use Base.Ordering with heaps #646
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note: this is basically a duplicate of #547, which still seems active. I wrote all this before finding that one, so I'm submitting it anyways just in case any of it is still useful.
Changes made:
comp::Comp
arguments and fields replaced withorder::Base.Ordering
everywhereLessThan
andGreaterThan
singleton types andcompare
function replaced withBase.Forward
,Base.Reverse
, andBase.Order.lt
.Ordering
as a constructor argument rather than a type parameter, because in general we can't get an instance from just the type (exception follows)const BinaryMinHeap{T} = BinaryHeap{T, typeof(Forward)}
andconst BinaryMaxHeap{T} = BinaryHeap{T, typeof(Reverse)}
, and similarly for mutable versionBinaryHeap
/MutableBinaryHeap
for these two special cases where the order is a singleton:BinaryHeap{T, typeof(Forward)}(...) = BinaryHeap{T}(Forward, ...)
etcBinaryHeap
,MutableBinaryHeap
,nsmallest
, andnlargest
now have methods with thelt
,by
, andrev
keyword arguments like insort
, which is more user-friendly than requiring anOrdering
instance.This introduces similar breaking changes as in #547 in that
isless
is now used for comparison by default instead of<
, which may yield different results whereNaN
s are involved (although, I would say that the previous behavior was undefined).I haven't updated or run the benchmark script yet so I don't know if there are any performance regressions.