#3416: Weierstrass form and Jacobian for cubics and certain other genus-one
curves
------------------------------------------------------------------------------+
Reporter: moretti |
Owner: was
Type: enhancement |
Status: needs_review
Priority: major |
Milestone: sage-5.7
Component: elliptic curves |
Resolution:
Keywords: nagell, weierstrass, cubic, elliptic curves, editor_wstein |
Work issues:
Report Upstream: N/A |
Reviewers: John Cremona, Marco Streng, Nils Bruin
Authors: Niels Duif, Volker Braun |
Merged in:
Dependencies: #12553, #13084, #13458 |
Stopgaps:
------------------------------------------------------------------------------+
Comment (by nbruin):
Replying to [comment:60 vbraun]:
> I don't particularly like adding extra keyword arguments to
`EllipticCurve` that only make sense in very special circumstances. If you
want to reduce the number of global symbols, which I'm all in favor of,
then one should combine the constructors into a class
`EllipticCurve.from_foobar()` to disambiguate.
Whether an (iso)morphism should be returned as well applies to more than
very special circumstances. When creating an elliptic curve from a given
algebraic curve plus rational point it's always relevant. In fact, keeping
track of the transformations involved really does cost extra work,
especially if you want the inverse as well. I doubt someone's going to
bother to write a faster version that doesn't track the morphism, but as a
general user interface it makes sense.
Routines are usually named after the thing they produce, so from
`EllipticCurve_from_cubic` one expects an elliptic curve.
`Isomorphism_from_cubic_curve_to_jacobian` would produce a morphism.
Unless you claim `EllipticCurve_from_cubic` is only an internal routine,
in which case it can return anything it likes.
I don't quite know how to return extra optional information. We could
return a tuple with as a second value the morphism so that we get the
extremely magmaesque
{{{
E,phi = EllipticCurve_from_cubic(x^3+y^3+z^3,[1,0,-1],morphism=True)
}}}
but that does mean the return type changes significantly upon supplying a
keyword argument. Mandating
{{{
E, = EllipticCurve_from_cubic(x^3+y^3+z^3,[1,0,-1],morphism=False)
}}}
seems a no-go.
I like the idea of returning morphisms to package up all relevant
information. I did so quite a bit in Magma. I've noticed that this wasn't
picked up by other users/authors, though, and that a few interface
routines grew that picked apart the morphisms and returned domain and
codomain separately. Perhaps that provides you with a data point of how
successful morphism-based return values are in practice. It seems the
majority of the mathematicians prefer to concentrate on the dots rather
than the arrows ...
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/3416#comment:61>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
