#3416: Weierstrass form for cubics
-------------------------------+--------------------------------------------
Reporter: moretti | Owner: was
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.7.1
Component: elliptic curves | Keywords: nagell, weierstrass, cubic,
elliptic curves, editor_wstein
Work_issues: | Upstream: N/A
Reviewer: Marco Streng | Author: Niels Duif
Merged: | Dependencies:
-------------------------------+--------------------------------------------
Comment(by nbruin):
Nice work! Haven't tested it, but I did scan over the patch. Some remarks:
- Your examples are misleading. You call {{{var("x y z")}}} and then
construct a polynomial ring. The call to {{{var}}} is irrelevant and
should be removed.
- Line 578. Why don't you take R=parent(F)? In fact, why do you define R
at all? I don't think you use it.
- Line 587. Don't use chord-tangent to determine if a point is a flex,
but see if the hessian (determinant of the matrix of double derivatives of
F) vanishes at P. That allows you to get rid of "chord_and_tangent" and of
"are_projectively_equivalent" (for which you should a library routine
instead of writing your own, if you really need it elsewhere. Sage's
projective spaces and their points should be able to do this for you.
For the interfacing with magma:
I think you can be a little more elegant here. Consider the following
example
{{{
R.<x,y,z>=QQ[]
f=x^3+y^3+z^3
P=(0,1,-1)
}}}
You can now do (and this should apply generally):
{{{
P2_magma=f.parent().magma().Proj()
C_magma=P2.Curve(f)
E_magma,mp_magma=C.EllipticCurve(C_magma(P),nvals=Integer(2))
E_magma.aInvariants().sage()
}}}
To extract the map, one would hope to be able to do
{{{
mp.DefiningPolynomials().sage()
}}}
and the fact that this fails is not really the fault of the code here. The
proper solution would be to extend the coercion system to the magma
interface, but that doesn't sound very appealing.
In any case, I don't think you should be hard-coding the Rationals as a
base ring here and you should not be calling MinimalModel either, because
you don't do that in the sage version.
---------------------------------------------------------
Finally, for the transformation: Yes, return a morphism or failing that, a
list of 3 homogeneous polynomials in the parent of F that would be the
appropriate input for the "hom" constructor.
If you are implementing your algorithm "bare bones" (internally, you just
work with polynomials and you don't use any of the scheme machinery and
your input consists of a homogeneous poly rather than a plane curve) there
could be some value of also making your output available "bare bones",
i.e., just return the list [a1,a2,a3,a4,a6] and a list of polynomials
describing the map.
There is a cost to using schemes, ambient spaces etc., so there may be a
benefit in having the raw functionality available in a form that avoids
it. Once you have a routine that does the heavy lifting, it's
straightforward to write a wrapper that provides an interface in scheme
language.
(there is also a benefit in using scheme language, so if you choose to
write your code in terms of such higher level constructs, it makes little
sense to wrap it to provide a "raw" interface as well)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/3416#comment:31>
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 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.
