-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Base.Ordering for heap, and other performance improvements #547
Conversation
Here are the expected benchmark results once the first 2 PRs are merged. There are occasional regressions for very small heaps (n = 10), but I suspect this is mostly due to Travis noise. Additional discussion of results. Here are the local results:
|
Codecov Report
@@ Coverage Diff @@
## master #547 +/- ##
==========================================
- Coverage 87.82% 87.67% -0.16%
==========================================
Files 32 32
Lines 2087 2053 -34
==========================================
- Hits 1833 1800 -33
+ Misses 254 253 -1
Continue to review full report at Codecov.
|
Here is the rule for deprecations:
So any time we bump the leading nonzero we can (and really should) remove all deprecations. |
beae028
to
1bc5464
Compare
@oxinabox I'm having trouble setting-up deprecation warnings, and could use some guidance. Here's an example of the API change: BinaryMinHeap{Int}() # old
BinaryMinHeap(Int) # new I was hoping something like this would work: @deprecate BinaryMinHeap{T}() where {T} BinaryMinHeap(T) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the getting rid of the LessThan
and GreaterThan
,
much better to use the Base
types.
it seems like this PR is undoing a lot of the work of
#472
which I don't understand.
I think you need |
I was unaware of #472, and don't want to undo previous changes, but types as arguments seems like a simpler way to construct heaps when passing either the Here's an example of the API that I'm proposing:
Let me know what constructor API you'd like to see instead. |
I would like to see the current API, |
I agree that the API should match Also changing floating point numbers to a partial order could result in surprising behavior with |
@dillondaudert @oxinabox A Here's a log showing the difficulties of constructing a
|
Yeah, fair call. We just need to add: |
@milesfrain sorry for the delay, was waiting to see if anyone upstream in JuliaLang objected to the addition of They did not. I will have it added to Compat.jl |
@oxinabox No worries. I was also waiting to see what happens with the |
Ok, @milesfrain you can now add a Compat v3 dependency, and start using the |
542695f
to
3e7e75f
Compare
I believe this latest changeset address all of your latest review feedback, but let me know if I missed anything, or if you have additional suggestions. I need some help troubleshooting why Travis is failing with Compat V3 and Julia 0.7. Local benchmark results:
|
We should just drop support for Julia 0.7. |
c5860d4
to
17c1578
Compare
@oxinabox Regarding the CI errors:
See the "construct heap" tests for examples of all the available heap constructors. Both immutable and mutable heaps match the requested API discussed earlier, but MinMax heap is missing a way to specify an element type along with an array of elements (e.g. |
I don't see any issue with adding |
Nightly is failing. because Julia nightly is I think a bit borked. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good from a quick-look,
but I haven't time to review this properly in the next 2 weeks.
@ararslan @kmsquire @scls19fr
could one of you give this a final look and bring it home?
Last thing is deprecations.
SemVer does not require us to do deprecations, if we are tagging this as a breaking change.
Which I think we should because I don't think we can easily depprecate it fully.
Maybe we can (if so that would be great)
Best instructions that exist from how to do deprecations. is the source:
https://github.com/JuliaLang/julia/blob/master/base/deprecated.jl
And examples in old versions of that file:
https://github.com/JuliaLang/julia/blob/v0.7.0/base/deprecated.jl#L398
@deprecate_binding
is really powerful.
What's missing for this to be tagged? |
I was just waiting on additional feedback:
But perhaps I was being a bit too patient. When reviewers are ready, I'll rebase.
I was hoping we could just make this a breaking change, rather than add partial deprecations. I don't think everything in this new version will translate fully via deprecations. |
Ok, I have taken another look. |
This is ready for review. Latest benchmark results show some minor regressions for the small (10^1 element) heaps. Might just be noise, since some differences are also reported for the untouched
|
I'm also curious what the best local testing workflow is.
With a temporary edit of the |
I think |
Sorry for they delay in this, just hoping to get a few more deprecations in before making the breaking change |
I didn't see this PR and essentially wrote a duplicate (#646) of it. Linking it here in case you would like to compare the two. |
Bummer about your duplicated effort @jlumpe . I've made that same mistake myself a few times. |
Ok finally we are in a position in master that we can merge this. |
oh, i didn't see this had been rebased. |
This merge sequence should be followed for generating useful benchmark comparisons:
@oxinabox This change introduces API changes, and deprecation warnings should be added. Could we replace the previous deprecation warnings with a version bump?