Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Trac #32490: multiplication_by_m_isogeny is only correct up to automo…
…rphism This is wrong: {{{#!sage sage: E = EllipticCurve(QQbar, [1,0]) sage: E.multiplication_by_m_isogeny(1).rational_maps() (x, -y) }}} {{{#!sage sage: E = EllipticCurve(GF(127), [1,0]) sage: P = E.random_point() sage: E.multiplication_by_m_isogeny(5)(P) (15 : 56 : 1) sage: 5*P (15 : 71 : 1) sage: -5*P (15 : 56 : 1) sage: E.multiplication_by_m(5) == (-E.multiplication_by_m_isogeny(5)).rational_maps() True }}} It isn't ''consistently'' wrong: {{{#!sage sage: E = EllipticCurve(QQ, [1,0]) sage: E.multiplication_by_m_isogeny(1).rational_maps() (x, y) }}} ---- The trouble is that the method first constructs **an** isogeny with the correct kernel and codomain, then sets the precomputed rational maps. However, the isomorphism to the prescribed codomain is not unique, and picking the wrong one means the resulting isogeny is off by an automorphism — most commonly `[-1]`. The patch is not pretty, but it seems to fix the issue for now and shouldn't cause any significant slowdowns. Once (if) #32388 gets in, we should probably instead use an `EllipticCurveHom` subclass specifically for scalar multiplications that imitates a normal isogeny but with different internals. I do have a draft of this ready and it's not only much cleaner, but also resolves part of #8014. URL: https://trac.sagemath.org/32490 Reported by: lorenz Ticket author(s): Lorenz Panny Reviewer(s): Travis Scrimshaw
- Loading branch information