-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Move most combinatorics code out of Base #13897
Conversation
- DROP 0.4 SUPPORT - Import most of base/combinatorics.jl (Ref: JuliaLang/julia#13897) - Move most of the special numbers to numbers.jl - Put combinations, permutations and partitions in their own files - Rename special numbers with ~num suffix. This renaming is particularly important for catalannum to avoid clashing with the Base.catalan irrational constant.
these should throw specific errors saying they're now in Combinatorics.jl the permutation functions like |
How should we handle the deprecations? The easiest thing I can think of is to add catchall methods like |
Agree; I would keep isperm, invperm, permute!, and ipermute!. I could go either way on factorial and gamma. Unfortunately the DSP code uses |
Put the DSP code in a package? |
I like the phrasing that was done for the PkgDev moves Line 63 in ce2500e
Though since these were exported, want to make sure Combinatorics.jl can extend them properly. |
Looks like rudimentary support for permutations is needed in Base, so I'll plan to put back
I'll also leave nextprod in with a note about its removal when DSP is removed. |
All other methods are moved to Combinatorics.jl
Should be ready for review |
Move most combinatorics code out of Base
Should there be a news entry for this? |
Yes. |
@@ -1044,13 +1044,6 @@ Compute the minimum absolute values over the singleton dimensions of `r`, and wr | |||
minabs! | |||
|
|||
doc""" | |||
prevprod([k_1,k_2,...], n) |
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.
These need to be manually removed from the rst docs. Again, keeping them in sync at the same time is a much clearer way to go right now.
This introduces a problem: in |
No it doesn't introduce any problem on 0.4. |
I misspoke - it's actually nightly builds that are affected:
See https://travis-ci.org/JuliaGraphs/LightGraphs.jl/jobs/90627799 for details. |
Yes, you will have to bear with the warning until the nightly builds are updated. A temporary workaround is to qualify the usage as the warning suggests: import Combinatorics: combinations I do this in the Combinatorics tests on master. |
The nightly in that run was from today. I think Combinatorics.jl should be checking if |
Warnings I can handle, but it's followed by an error (see edited comment). It stinks because the "failed build" badge shows up on the project's home page as a result, and integration tests for PRs are all failing. I'm fully qualifying it now. |
Oh good point. I'll have to |
Yes, though it'll be a little more future-proof if you use |
Thanks for the quick response. Let me know if/how I can help. |
I'm not going to write isdefined(:...) for 8 different functions. |
Please don't use a version number comparison, do a feature check. Otherwise the versions of the package you write now are guaranteed to break as soon as the deprecations get removed. edit: hrm, maybe I spoke too soon, importing something nonexistent is only a warning? Did not expect that. Still, version number checks are just generally brittle and bad practice, and don't work when you do a |
On 0.5, the 8 functions excised from Base are still defined, as they have methods that print the error to use Combinatorics.jl. Ref: JuliaLang/julia#13897 (comment)
On 0.5, the 8 functions excised from Base are still defined, as they have methods that print the error to use Combinatorics.jl. Ref: JuliaLang/julia#13897 (comment)
I've included an isdefined check on Base.combinations, on the premise that we will excise all 8 deprecation errors at once. |
On 0.5, the 8 functions excised from Base are still defined, as they have methods that print the error to use Combinatorics.jl. Ref: JuliaLang/julia#13897 (comment)
OK, I'm a bit confused here. How is one supposed to write code that uses Advice greatly appreciated. Thanks. |
Could you tag a version of Combinatorics.jl that only supports 0.4.X and just re-exports the functions from Base? |
There shouldn't be any problems. Tested on JuliaBox
Note that you shouldn't require |
Ah, that's likely the issue - I had 0.3.1 specified in REQUIRE. Let's see what happens when I remove the version. |
|
@tkelman I can, but what about the users of the package? I'd hate to leave folks out in the cold. ETA: and I'm on 0.4.2-pre+3, so I'm a bit puzzled. |
@tkelman It's |
Actually Polynomial should only be deprecated for releases of 0.4, so my mistake, the issue was the version number of Combinatorics you were trying to require. Pkg resolution failures don't always give the most informative errors right now, there are one or two issues on this. |
Thanks for the prompt responses (as usual!) - testing LG now without version numbers in Combinatorics. There are lots of moving parts these days, and trying to keep the packages testing cleanly on both 0.4 and 0.5 is taxing work. ETA: ok, removing the version number fixes the problems on 0.4 and 0.5. (now to figure out the other failures.) Thanks again. |
This PR extracts all combinatorics functions from Julia's
Base
library, except for:binomial
,factorial
, andgamma
isperm
,invperm
,permute!
,ipermute!
nextprod
which is used inBase.DSP
All other functions are to be migrated to https://github.com/JuliaLang/Combinatorics.jl
See: JuliaMath/Combinatorics.jl#8
Ref: #5155