Make EllipticCurveIsogeny objects faster to create via lazy evaluation
#8014
Assignees
Comments
|
comment:1
See also #7368 for an isogeny wishlist. Chris W and I have lots of other ideas for redesigning the isogeny code. At present it consists of a lot of intricately related functions and the code is hard to get into. And the file ell_curve_isogeny.py is very long (4790 lines): I plan to move lines 3733 to the end when we add implementations for {2,3,5,7,13}-isogenies in characteristics {2,3} for {j=0, j!=0}, which are currently being worked out by my student Kimi (522=20 special cases!) |
|
comment:3
The performance issues of |
This was referenced Oct 23, 2021
kryzar
pushed a commit
to kryzar/sage
that referenced
this issue
Feb 6, 2023
…curves This ticket adds `EllipticCurveHom_scalar`, a new class encapsulating scalar multiplications on elliptic curves. This serves two main purposes: 1. It solves one of the motivations behind sagemath#8014 (faster `multiplication_by_m_isogeny`). 2. Wrapping scalar multiplications as an `EllipticCurveHom` is an important step towards implementing endomorphism rings (see sagemath#7368). We also deprecate `.multiplication_by_m_isogeny()`: It should be replaceable by `.scalar_multiplication()` in all cases. URL: https://trac.sagemath.org/32826 Reported by: lorenz Ticket author(s): Lorenz Panny Reviewer(s): John Cremona
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, it's quite slow to create an
EllipticCurveIsogenyobject, because it precomputes a huge amount of information about itself. (This blocks the original request at #7262, for instance.) It seems like it would be easy enough (and generally useful!) to speed up creation of isogeny objects, and have them lazily evaluate the appropriate bits as needed. Then one could unify themultiplication_by_mandmultiplication_by_m_isogenymethods, for instance (maybe by deprecating the former?).That said, I haven't spent much time with the isogeny code -- if there's some obvious reason this is a bad idea, please comment on the ticket.
CC: @JohnCremona @categorie @shumow @yyyyx4
Component: elliptic curves
Issue created by migration from https://trac.sagemath.org/ticket/8014
The text was updated successfully, but these errors were encountered: