-
-
Notifications
You must be signed in to change notification settings - Fork 482
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
new iterators over the partitions of an integer #38054
new iterators over the partitions of an integer #38054
Conversation
The fastest is sage: from sage.combinat.partitions import ZS1_iterator, ZS2_iterator, AccelDesc_iterator, AccelAsc_iterator
sage: %timeit sum(1 for _ in ZS1_iterator(10))
10.8 µs ± 29.4 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)
sage: %timeit sum(1 for _ in ZS2_iterator(10))
12 µs ± 108 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)
sage: %timeit sum(1 for _ in AccelDesc_iterator(10))
10.9 µs ± 7.62 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)
sage: %timeit sum(1 for _ in AccelAsc_iterator(10))
10.8 µs ± 73.1 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)
sage:
sage: %timeit sum(1 for _ in ZS1_iterator(50))
47.8 ms ± 393 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
sage: %timeit sum(1 for _ in ZS2_iterator(50))
52.1 ms ± 61.6 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
sage: %timeit sum(1 for _ in AccelDesc_iterator(50))
47.4 ms ± 45.1 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
sage: %timeit sum(1 for _ in AccelAsc_iterator(50))
46.4 ms ± 44.8 µs per loop (mean ± std. dev. of 7 runs, 10 loops each) |
Documentation preview for this PR (built with commit c5c4a3e; changes) is ready! 🎉 |
linting errors? |
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.
At least it seems like we should not use ZS2
over AccelAsc
for increasing lex iteration by default. I am not opposed to keeping both implementations with some test for a sufficiently large n
(say, between 50 and 100) showing the outputs are equal at every step.
I think we should add a prev
method to partitions as well.
Other than that, I am good with this.
The orderings are not the same. Both generate partitions in lexicographic order, but the partitions of
done. |
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.
Thank you.
At least it seems like we should not use
ZS2
overAccelAsc
for increasing lex iteration by default. I am not opposed to keeping both implementations with some test for a sufficiently largen
(say, between 50 and 100) showing the outputs are equal at every step.The orderings are not the same. Both generate partitions in lexicographic order, but the partitions of
ZS2
are in descending order while the partitions ofAccelAsc
are in ascending order. So both might be of interest for some users.
To me, a partition is always a weakly decreasing sequence (or a multiset), but yes, I agree that having the reverse order within the lists could be useful.
Just a few more minor things.
Co-authored-by: Travis Scrimshaw <[email protected]>
Thanks for the comments. |
The bot is showing some failures:
I am not sure how many of them are real failures due to the changes here. Some seem unrelated from the log. |
This seems unrelated. On my side, I don't observe these errors. I only see 1 warning
|
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.
Thanks for checking. I also saw today that that group of errors was reported on sage-release. So positive review.
Thank you for the review. |
As discussed in sagemath#37977, we implement new iterators over the partitions of an integer to get iterators generating partitions in increasing/decreasing lexicographic orders with partitions in ascending/descending orders. We also implement methods yielding the next partition in a specific ordering. ### 📝 Checklist <!-- Put an `x` in all the boxes that apply. --> - [x] The title is concise and informative. - [x] The description explains in detail what this PR is about. - [x] I have linked a relevant issue or discussion. - [x] I have created tests covering the changes. - [x] I have updated the documentation and checked the documentation preview. ### ⌛ Dependencies <!-- List all open PRs that this PR logically depends on. For example, --> <!-- - sagemath#12345: short description why this is a dependency --> <!-- - sagemath#34567: ... --> URL: sagemath#38054 Reported by: David Coudert Reviewer(s): David Coudert, Travis Scrimshaw
As discussed in #37977, we implement new iterators over the partitions of an integer to get iterators generating partitions in increasing/decreasing lexicographic orders with partitions in ascending/descending orders.
We also implement methods yielding the next partition in a specific ordering.
📝 Checklist
⌛ Dependencies