#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 shumow):
I can't say anything cogent about the math, from an API perspective, what
I would say is the following:
1) When determining the codomain model, I think that the default behavior
should be to do whatever the underlying formulas do. However, if the user
wishes this to be overridden they should be able to do so. It sounds like
the two cases of interest are:
a) If the user explicitly specifies an isomorphic model to the
calculated codomain. This would be specified by setting the codomain
parameter in the Isogeny constructor.
b) In the case of curves over the rationals, if the user sets a flag
named something like compute_minimal_codomain, the isogeny should be setup
to compute evaulate to the minimal model of the codomain.
2) D. Kohel's advice re: a function that just calculates the codomain only
is a good idea. I will implement that.
I am mainly interested in the finite field case, so I have a question: In
the rational case, is the option to compute the isogeny to the minimal
model something that would be useful?
I think doing what the underlying formulas say be default is the clearest
thing from the perspective of the API. But we still definitely want to
give users the ability to override this.
Also, I am not concerned about finding a canonical codomain model in the
numberfield case. That seems somewhat out of the scope of this class,
unless there is something that is clearly the right choice? (From the
above interchange it seems like there is not a clear choice.)
To give a rough idea of the signature of the constructor I am thinking of:
isogeny_from_kernel(
kernel, codomain=None, order=None, compute_minimal_model=False,
algorithm=None)
The inputs are thus:
kernel : the kernel of the isogeny, necessary, unless the codomain is
specified and one of the isogeny from domain/codomain algorithms is used.
codomain : the codomain curve, if one other than Velu's choice is
desired, OR if we are calculating the isogeny based on the domain/codomain
algorithm
order : the order of the kernel (this can be inferred, but can bypass
a gcd with the 2-torsion polynomial). Also necessary in the case that a
domain/codomain algorithm is used.
compute_minimal_model : In the case of a curve over the rationals this
calculates the isogeny such that the codomain model is the minimal
weierstrass model.
algorithm : this was 'velu' or 'kohel', but is now partially
redundant. I plan to write the code to look at this, and if it is NOT
present then it will try to determine the algorithm from the input
parameters.
Does this sound good to everyone?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/5976#comment:19>
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
-~----------~----~----~----~------~----~------~--~---
