#5976: [with patch; needs work] Add an Elliptic Curve Isogeny object
---------------------------+------------------------------------------------
Reporter: shumow | Owner: shumow
Type: enhancement | Status: assigned
Priority: major | Milestone: sage-4.0
Component: number theory | Keywords: Elliptic Curves
---------------------------+------------------------------------------------
Comment(by cremona):
Replying to [comment:11 shumow]:
> Replying to [comment:10 cremona]:
> > That is probably right, but how do you define "normalised"? I think
the definition is that the pull-back of the standard differential w_E =
dx/(2y+a1*x+a3) under the isgeny is again the standard differential; for
[m] the pull-back of w is m*w. Obviously this only makes sense for
separable isogenies, since otherwise the pull-back of w is 0.
> >
> > Or do you in fact mean "cyclic" isogeny?
> >
> > We definitely need to be able to handle non-normalised isogenies, if
only because the dual of a normalised isogeny is not normalised (using my
definition above).
> >
> > I'm in a rush, so apologise if this is nonsense.
>
> I don't mean "cyclic" isogeny. Yes, I meant the definition using the
pullback of the invariant differential, which I believe is equivalent to
that characterization that the isogeny map is defined by: (I(x),
c*y*I'(x)) and c == 1. Where I(x) is a rational map given by the various
different formulas/algorithms.
OK, that's the definition I meant. (e.g. with this definition,
multiplication-by-m is normalised iff m=1, since c=m). Except that the
precise characterization you give is only correct when the curve has short
Weierstrass form (y^2=f(x)). Otherwise it something like (I(x),
cI'(x)(y+(a1*x+a3)/2) - (A1*I(x)+A3)/2) where E=[a1,a2,a3,...] and the
isogenous curve is [A1,A2,...].
>
> I agree with you that we should support non normalized. When I was
doing some testing, I was calculating the "normalized dual" meaning the
normalized isogeny to an isomorphic curve, and post composing w/ an
isomorphism, to make sure I had the right thing.
>
> I think the way to handle non-normalized isogenies is to have a post
isomorphism (and possibly pre isomorphism) that gets applied after the
normalized isogeny does. I'm not sure the best way to specify this in the
constructor, but I haven't thought about it a lot. What are your thoughts
on this?
Since we are specifying the isogeny from its kernel, it is well-defined up
to an automorphism, so usually up to +/-1 (with the usual awkward special
cases). So if the user asks for an isogeny with a given kernel they
surely don't get to specify whether or not it is normalised (except for
the sign)?
>
> I as well am in a hurry, so apologies if what I am saying here didn't
make sense.
I am hoping that David Kohel will comment, since he is the real expert on
all this!
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/5976#comment:12>
Sage <http://sagemath.org/>
Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
