#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.1
Component: number theory | Keywords: Elliptic Curves
---------------------------+------------------------------------------------
Comment(by kohel):
Replying to [comment:20 cremona]:
> That all sounds very good to me. Yes, over the rationals (and number
fields) one is definitely interested in having specific models of the
codomain. We can add extra bits for the number field case later.
Over finite fields too -- if one begins with a given model then one often
wants to have that model for the codomain.
> There are of course some striking differences between the number field
and finite field cases. Over finite fields, when two curves are isogenous
there are infinitely many isogenies (e.g.in the ordinary case, the
isogenies form a rank 1 projective module over the endomorphism ring), so
it would not be sufficient just to give the two curves; one might also
want to give a possible degree. While over number fields (and more
generally in char. 0) there is less choice.
It is a much harder problem to determine an isogeny given two curves (over
a finite field or not). I don't think we're discussing this (interesting)
problem, rather, given a curve, kernel polynomial, the possibly a codomain
curve (e.g. the domain, if the kernel polynomial is known to determine an
endomorphism).
Anyway, I don't find the number field and finite field cases that
dissimilar. Ordinary curves at least lift to CM curves over H/K (or a
local field) over which the isogenies lift from finite characteristic, and
even in the generic (non-CM) case, at primes of good reduction, the (few)
isogenies which exist over the ground field are just the rational points
in an infinite graph which is a universal cover (containing the
l+1-regular tree for each prime degree l) of the isogeny graph the residue
field. Over the number field, one just wants finer control over what
happens simultaneously at all primes, and I view isogenies over number
fields as an 'intersection' over all finite primes of reduction (a global
isogeny with image in the product of all local isogenies).
In all cases, Velu gives a preferred choice of normalization, which we can
efficiently modify with a pullback scalar, or by requesting a particular
codomain model such as the minimal model.
On that note, rather than 'compute_minimal_model', I would suggest just
'model' (default None or 'velu') so that one can do:
E.isogeny_from_kernel(psi,model='minimal')
in order to induce the computation of a minimal model (for the codomain).
I think it is clear that 'model' only refers to the codomain which is that
which is computed. This is flexible enough to also allow for standard
models {'edwards', 'montgomery', 'hessian', 'legendre',
'short_weierstrass', 'binary_weierstrass', etc.} in vogue in cryptographic
settings.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/5976#comment:21>
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
-~----------~----~----~----~------~----~------~--~---
