-
-
Notifications
You must be signed in to change notification settings - Fork 477
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
opportunistic caching of elliptic-curve and point orders #32786
Comments
This comment has been minimized.
This comment has been minimized.
Commit: |
Author: Lorenz Panny |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:4
Bot is green except for #32737. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:9
Stalled in |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:11
Member function in PARI/GP does not really exist. They only exist in the gp language. For cypari2, they are only available at C-level not from Python. Some of them are wrapped in cypari2 such as bnf_get_fu. Could you open an issue for cypari2 with the list of member functions that would be desirable to have ? Note that we have a long standing issue about automation sagemath/cypari2#51. |
comment:12
That particular comment was about the |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:15
In any case, I don't really see a reason to wait with the changes here until cypari2 can do the thing we'd like. This patch already produces huge speedups: For example, one of my scripts (dealing with elliptic curves over a finite field of ~160 bits) runs in 9 seconds after the patch compared to 25 seconds before. |
comment:16
I agree that it would be good to take what we have in hand (since it is worth more than 2 improvements in the bush). My only comment would be why not use a |
comment:17
Sounds reasonable, but I can't get that to work without causing infinite recursions (the superclass ends up calling back into the |
Reviewer: Travis Scrimshaw |
comment:18
Hmm...it seems like the action is implemented in a different way (the base class
This is more future proof in case a specialized action gets implemented (although it is effectively the same code). |
comment:19
Same issue: The I suppose one thing we could do is to implement |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:21
Right...we are running into this problem because of how the action is implemented (in a very generic way) and this is the first non-generic version. No, this is good. I don't think we need to go to any great lengths for something that might be implemented in the future. Thank you. |
comment:22
Great, thank you! |
Changed branch from public/opportunistic_caching_of_curve_and_point_orders to |
… point orders This is a follow-up to sagemath#32786 with the following changes: - Copy curve orders between domain and codomain for all `EllipticCurveHom` instances of nonzero degree, rather than (previously) just `EllipticCurveIsogeny` objects. - Copy point orders when pushing a point through an isomorphism. - Copy point orders when pushing a point through an isogeny of degree coprime to the point order. - Rearrange some computations in the √élu code (sagemath#34303, sagemath#34614) to make (better) use of cached orders; in particular, this unbreaks the use of `.set_order()` on the kernel point prior to passing it to `EllipticCurveHom_velusqrt`. [Thanks to Jonathan Komada Eriksen for reporting this last issue.] URL: https://trac.sagemath.org/34732 Reported by: lorenz Ticket author(s): Lorenz Panny Reviewer(s): Travis Scrimshaw
There are various places in the elliptic-curve code where we could reuse known information about curve and point orders:
order_from_multiple
in general). It's unclear if this is worthwhile in all cases.Moreover,
EllipticCurvePoint_finite_field
currently uses its_order
attribute whenever present, but the.order()
method fails to actively cache_order
after it's been computed. We should also copy over the curve order after computing a point order because it's computed and cached by PARI anyway.The patch implements items 1-3 of the list and fixes the
_order
caching inEllipticCurvePoint_finite_field
.CC: @defeo @JohnCremona
Component: elliptic curves
Author: Lorenz Panny
Branch/Commit:
a4138a9
Reviewer: Travis Scrimshaw
Issue created by migration from https://trac.sagemath.org/ticket/32786
The text was updated successfully, but these errors were encountered: