Skip to content

Improve FiniteField_givaroElement #40713

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 2 commits into
base: develop
Choose a base branch
from
Open

Improve FiniteField_givaroElement #40713

wants to merge 2 commits into from

Conversation

user202729
Copy link
Contributor

@user202729 user202729 commented Aug 28, 2025 •
edited
Loading

General speedup, plus some minor clean-up.

The worst offenders are log and multiplicative_order which uses the generic algorithm.

📝 Checklist

  • The title is concise and informative.
  • The description explains in detail what this PR is about.
  • I have linked a relevant issue or discussion.
  • I have created tests covering the changes.
  • I have updated the documentation and checked the documentation preview.

⌛ Dependencies

@github-actions GitHub Actions
Copy link

github-actions bot commented Aug 29, 2025 •
edited
Loading

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

@user202729 user202729 force-pushed the improve-finite-field-givaro branch from c250f64 to cb84476 Compare August 29, 2025 14:54
@user202729 user202729 force-pushed the improve-finite-field-givaro branch from cb84476 to 0a5d0b7 Compare August 29, 2025 17:38
vneiger
vneiger reviewed Aug 30, 2025
View reviewed changes
src/sage/rings/finite_rings/element_givaro.pyx
@@ -1411,35 +1433,25 @@ cdef class FiniteField_givaroElement(FinitePolyExtElement):
- ``check`` -- boolean (default: ``False``): If set,
test whether the given ``order`` is correct.
Copy link
Contributor

Choose a reason for hiding this comment

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

If I'm not mistaken, order is unused in the new version, apart from checking: it nevers helps for performance or correctness, but may make it worse if provided with check=True. I suppose there is a good reason against removing order and check (?), but maybe to avoid confusion for the user, the doc could indicate that providing order will not speed up anything?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

just for backwards compatibility, some existing code e.g. .log(self, a, b) in elliptic curve point passes the order.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, thanks.

@vneiger
Copy link
Contributor

vneiger commented Aug 30, 2025

Apart from the comment on order, other changes look good to me

@vneiger
Copy link
Contributor

vneiger commented Aug 31, 2025

The changes look good to me. Thanks

@vneiger vneiger self-requested a review August 31, 2025 07:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
1 more reviewer

@vneiger vneiger vneiger approved these changes

Reviewers whose approvals may not affect merge requirements
Assignees
No one assigned
Labels
c: finite rings s: positive review t: performance
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@user202729 @vneiger