Skip to content
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 the faster binomial in combinat #39385

Open
wants to merge 4 commits into
base: develop
Choose a base branch
from

Conversation

fchapoton
Copy link
Contributor

as the binomial method of integers is way faster than the general purpose binomial from arith.misc

also a few other minor code changes

📝 Checklist

  • The title is concise and informative.
  • The description explains in detail what this PR is about.

Copy link
Contributor

@vincentmacri vincentmacri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, a suggestion and a question before I approve.

Suggestion: I think some of your casts to ZZ/Integer might be redundant, in that I think it's already set to be a Sage integer by the parent/elsewhere. The redundant casts to ZZ adds a non-negligible performance cost so remove those if they aren't needed. (a = Integer(5) takes about 215 ns on my machine, a = b where b = ZZ(5) takes about 15 ns).

Question: What is the difference between ZZ(x) and Integer(x)? In some places you use ZZ(x) and in some places you changed ZZ(x) to Integer(x).

@@ -77,13 +76,13 @@ def __init__(self, parent, lst, check=True):
"""
if check:
lst = [ZZ(val) for val in lst]
self.k = parent.k
self.k = ZZ(parent.k)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this ZZ call necessary? In the __init__ for AffinePermutationGroupGeneric, you have self.k = ZZ(ct.n) so I think parent.k will always be a Sage integer unless there's some other code path that bypasses the existing cast.

Even in Sage 10.5 I don't see how to construct this object in a way that you don't get a Sage integer here.

@@ -332,7 +332,7 @@ def __init__(self, data, frozen=None, is_principal=False, user_labels=None, user
else:
labelset = set(user_labels)
# Sanitizes our ``user_labels`` to use Integers instead of ints
user_labels = [ZZ(x) if x in ZZ else x for x in user_labels]
user_labels = [Integer(x) if x in ZZ else x for x in user_labels]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the purpose of this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is marginally faster

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then shouldn't we be using Integer throughout this PR instead of ZZ?

Copy link

github-actions bot commented Jan 28, 2025

Documentation preview for this PR (built with commit db52fb0; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

@@ -2014,13 +2014,13 @@ def __init__(self, cartan_type):
"""
Parent.__init__(self, category=AffineWeylGroups())
ct = CartanType(cartan_type)
self.k = ct.n
self.k = Integer(ct.n)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question as earlier: from my reading of the code, ct.n will always be a Sage integer, so this cast should be unnecessary. Is there any reason you have Integer(ct.n) here instead of ct.n? I did some timing experiments and calling Integer does slow things down, and from the PR title this is supposed to be an optimization PR.

There are a few other locations in the code where you're calling Integer on something that I think is already going to be a Sage integer.

@fchapoton
Copy link
Contributor Author

fchapoton commented Jan 31, 2025

I have double-checked "poset", "pieri_factors" and "shuffle_product" and Integer is needed there. Could you please point to where else you think it may not be needed, besides "affine_permutation" ?

The Integer around ct.n cannot be removed in affine_permutation

@vincentmacri
Copy link
Contributor

I have double-checked "poset", "pieri_factors" and "shuffle_product" and Integer is needed there. Could you please point to where else you think it may not be needed, besides "affine_permutation" ?

All I wanted was to double-check that the uses of Integer are required.

LGTM!

vbraun pushed a commit to vbraun/sage that referenced this pull request Feb 3, 2025
    
as the binomial method of integers is way faster than the general
purpose binomial from `arith.misc`

also a few other minor code changes

### 📝 Checklist

- [x] The title is concise and informative.
- [x] The description explains in detail what this PR is about.
    
URL: sagemath#39385
Reported by: Frédéric Chapoton
Reviewer(s): Frédéric Chapoton, Vincent Macri
vbraun pushed a commit to vbraun/sage that referenced this pull request Feb 4, 2025
    
as the binomial method of integers is way faster than the general
purpose binomial from `arith.misc`

also a few other minor code changes

### 📝 Checklist

- [x] The title is concise and informative.
- [x] The description explains in detail what this PR is about.
    
URL: sagemath#39385
Reported by: Frédéric Chapoton
Reviewer(s): Frédéric Chapoton, Vincent Macri
vbraun pushed a commit to vbraun/sage that referenced this pull request Feb 9, 2025
    
as the binomial method of integers is way faster than the general
purpose binomial from `arith.misc`

also a few other minor code changes

### 📝 Checklist

- [x] The title is concise and informative.
- [x] The description explains in detail what this PR is about.
    
URL: sagemath#39385
Reported by: Frédéric Chapoton
Reviewer(s): Frédéric Chapoton, Vincent Macri
vbraun pushed a commit to vbraun/sage that referenced this pull request Feb 9, 2025
    
as the binomial method of integers is way faster than the general
purpose binomial from `arith.misc`

also a few other minor code changes

### 📝 Checklist

- [x] The title is concise and informative.
- [x] The description explains in detail what this PR is about.
    
URL: sagemath#39385
Reported by: Frédéric Chapoton
Reviewer(s): Frédéric Chapoton, Vincent Macri
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants