Weierstrass form and Jacobian for cubics and certain other genus-one curves

[bobmoretti]

Implement transformations to put a general cubic (with a point) into Weierstrass form:

sage: R.<u,v,w> = QQ[]
sage: EllipticCurve(u^3+v^3+w^3, [1,-1,0])   
Elliptic Curve defined by y^2 + 2*x*y - 1/3*y = x^3 - x^2 + 1/3*x - 1/27 over Rational Field
sage: EllipticCurve_from_cubic(u^3+v^3+w^3, [1,-1,0])
Scheme morphism:
  From: Closed subscheme of Projective Space of dimension 2 over Rational Field defined by:
  u^3 + v^3 + w^3
  To:   Elliptic Curve defined by y^2 + 2*x*y - 1/3*y = x^3 - x^2 + 1/3*x - 1/27 over Rational Field
  Defn: Defined on coordinates by sending (u : v : w) to
        (w : -v - w : -3*u - 3*v)

Also, Jacobians (without specifying point):

sage: R.<u,v,w> = QQ[]
sage: Jacobian(u^3+v^3+w^3)
Elliptic Curve defined by y^2 = x^3 - 27/4 over Rational Field
sage: Jacobian(u^3+v^3+w^3, morphism=True)
Scheme morphism:
  From: Projective Curve over Rational Field defined by u^3 + v^3 + w^3
  To:   Elliptic Curve defined by y^2 = x^3 - 27/4 over Rational Field
  Defn: Defined on coordinates by sending (u : v : w) to
        (u*v^7*w + u*v^4*w^4 + u*v*w^7 : v^9 + 3/2*v^6*w^3 - 3/2*v^3*w^6 - w^9 : -v^6*w^3 - v^3*w^6)

Apply:

• attachment: trac_3416_elliptic_curve_from_cubic_vb.patch
• attachment: trac_3416_jacobians.patch
• attachment: trac_3416_fixes.patch
• attachment: trac_3416_magma.patch

See attachment: cubic_to_weierstrass_documentation.pdf for details on how the algorithm works.

Depends on #12553
Depends on #13084
Depends on #13458

CC: @novoselt

Component: elliptic curves

Keywords: nagell, weierstrass, cubic, editor_wstein

Author: Niels Duif, Volker Braun

Reviewer: John Cremona, Marco Streng, Nils Bruin

Merged: sage-5.12.beta3

Issue created by migration from https://trac.sagemath.org/ticket/3416

[wdjoyner]

comment:1

Attachment: weier.patch.gz

Since y^2 = quartic is also genus 1, I'm curious if there is a corresponding function planned to compute the Weierstrass form of a quartic hyperelliptic.

[williamstein]

comment:2

You can't give your own code a negative review :-). I changed it to "not ready for review".

[craigcitro]

Changed keywords from nagell, weierstrass, cubic to nagell, weierstrass, cubic, editor_wstein

[syazdani77]

Attachment: Weierstrass.sage.gz

Algorithm 7.4.10 of GTM 138

[sagetrac-Niels]

comment:5

I believe the formulas used here are incorrect. I'm not sure, but they appear similar to the erroneous formula's from Cohen's book. I'm currently working on an implementation that uses different formulas. I expect that to be done within two weeks.

One of my colleagues is working on y² = quartic, which I will implement for him. I expect this to be done within a couple of weeks. During Sage Days 23 plans were made for other curves too, but I'm not sure anyone is working on those.

[williamstein]

comment:6

Replying to @sagetrac-Niels:

I believe the formulas used here are incorrect. I'm not sure, but they appear similar to the erroneous formula's
from Cohen's book. I'm currently working on an implementation that uses different formulas.
I expect that to be done within two weeks.

Yes, they are definitely the wrong formulas in Cohen's book.

-- William

[JohnCremona]

comment:7

Henri Cohen writes (2010-08-12):

Concerning the formulas for a general cubic in my first book, the situation is precisely the following:

1) They were directly copied from an APECS script written by Ian Connell.

2) The final Weirstrass equation is correct, as is the transformation from
the cubic coordinates to the Weierstrass ones. On the other hand, the reverse
transformation has a mistake, which I never took time to find, should be easy
(it may be the other way round).

3) This is in my errata sheets. In my more recent books, I indicate that there is indeed a
mistake, and explain the algorithm (well-known of course), in less detail with no explicit
formulas, so that a student should be able to reconstruct them.

This suggests that very minor corrections are all that is required.

[nbruin]

comment:8

I have found that the descriptions in:

Cassels, J. W. S. Lectures on elliptic curves. London Mathematical Society Student Texts, 24. Cambridge University Press, Cambridge, 1991.

give excellent recipes for writing down isomorphisms from cubics, y!^2=quartic and intersections of two quadrics in P!^2 with a rational point to their Jacobians in weierstrass form.

The alternative method of writing down maps of degrees 3, 2, 4 (respectively) to their Jacobians using invariant theory (see Tom Fisher et al.) often results in nicer models, because there are less arbitrary choices to be made.

[JohnCremona]

comment:9

Replying to @nbruin:

I have found that the descriptions in:

Cassels, J. W. S. Lectures on elliptic curves. London Mathematical Society Student Texts, 24. Cambridge University Press, Cambridge, 1991.

give excellent recipes for writing down isomorphisms from cubics, y!^2=quartic and intersections of two quadrics in P!^2 with a rational point to their Jacobians in weierstrass form.

The alternative method of writing down maps of degrees 3, 2, 4 (respectively) to their Jacobians using invariant theory (see Tom Fisher et al.) often results in nicer models, because there are less arbitrary choices to be made.

Sure, and it would be great to have all these genus one modes in Sage!

(you can call me) al

[sagetrac-Niels]

comment:10

Replying to @nbruin:

I have found that the descriptions in:

Cassels, J. W. S. Lectures on elliptic curves. London Mathematical Society Student Texts, 24. Cambridge University Press, Cambridge, 1991.

give excellent recipes for writing down isomorphisms from cubics, y!^2=quartic and intersections of two quadrics in P!^2 with a rational point to their Jacobians in weierstrass form.

The alternative method of writing down maps of degrees 3, 2, 4 (respectively) to their Jacobians using invariant theory (see Tom Fisher et al.) often results in nicer models, because there are less arbitrary choices to be made.

Thanks for the advice. I will browse through the suggested literature to find the most convenient way of implementing cubic to Weierstrass. I plan to finish this before the end of August.

If I have more time I will try some quartics and see whether I can get the nicer formulas using J-invariants.

[sagetrac-Niels]

Attachment: 14532.patch.gz

[sagetrac-Niels]

comment:11

Attachment: cnotes.pdf.gz

Here is my first ever Sage patch: 14532.patch. It creates an elliptic curve from any homogeneous cubic. The cubic is transformed to Weierstrass, and birational maps between the equations are given. The case y² = quartic is not covered.

The patch is based upon Sage 4.4.4.

The used transformations are from Section 4.4 of the course notes: "G1CRPC: Rational Points on Curves", which I uploaded as cnotes.pdf.

Please review my patch, and provide extensive feedback.

[JohnCremona]

comment:13

Just a couple of quick comments, as I have not yet had a chance to look at the patch properly or try it out. First: I'm not sure we really want my old lecture notes attached to this ticket! There is nothing you are using there that is not in standard other sources. But if they are there, they should be attributed ;)

Secondly, you absolutely cannot have print statements giving part of the output as a side-effect. Better to return a tuple consisting of the elliptic curve and the morphisms. This will break backwards compatibility, since the Magma version does not so this (though he underlying Magma function surely does), but it could be controlled by an extra parameter which defaults to False.

[sagetrac-Niels]

comment:14

Replying to @JohnCremona:

I'm not sure we really want my old lecture notes attached to this ticket! There is nothing you are using there that is not in standard other sources. But if they are there, they should be attributed ;)

The problem is that most of the standard other sources contain incorrect formulas. These lecture notes are the first source I found with correct formulas. The main reason for including them is that it may help people in reviewing the patch. If anyone finds the same transformations in a standard source, please let me know.

Secondly, you absolutely cannot have print statements giving part of the output as a side-effect. Better to return a tuple consisting of the elliptic curve and the morphisms. This will break backwards compatibility, since the Magma version does not so this (though he underlying Magma function surely does), but it could be controlled by an extra parameter which defaults to False.

Ok, I can change that. Is there nice a way to represent such a morphism in Sage? I have difficulty expressing a transformation like the following as a single morphism (just an example from the top of my head):

x -> x² - y

y -> x² + y

z -> z²

Then multiply with 6/(x² z)

[JohnCremona]

comment:15

I tried to define the morphism properly, which should work, but it doesn't since in defining the morphism Sage checks that the polynomials used a homogeneous of the same degree (see line 458 of schemes.generic.morphism.py), but the degree function is not defined for elements of the coordinate ring. This can be fixed: although in general QuotientRingElement s have no degree, in this situation (where the quotient is by a homogeneous ideal) the degree is well-defined.

[JohnCremona]

comment:16

See #10297 for a separate report on this (and, soon, a patch).

[JohnCremona]

comment:17

Replying to @JohnCremona:

See #10297 for a separate report on this (and, soon, a patch).

The patch is there, so please review it! The example I used there is one of the examples from the patch here.

Replacing the curve E used there with

sage: E=EllipticCurve([0,0,0,0,-6400/3])
sage: H=C.Hom(E)
sage: f = H([zbar,xbar-ybar,-(xbar+ybar)/80])
sage: f
Scheme morphism:
  From: Projective Curve over Rational Field defined by x^3 + y^3 + 60*z^3
  To:   Elliptic Curve defined by y^2 = x^3 - 6400/3 over Rational Field
  Defn: Defined on coordinates by sending (x : y : z) to
        (zbar : xbar - ybar : -1/80*xbar - 1/80*ybar)

successfully defines the morphism. I recommend that the function here just returns the morphism, since one can recover E from

sage: f.codomain()
Elliptic Curve defined by y^2 = x^3 - 6400/3 over Rational Field

This will not be the end of the story, as I now cannot apply f to a point on C to get a point on E, but that's because of another difficulty like the one at #10297, so should be fixed separately.

[JohnCremona]

comment:77

Replying to @vbraun:

The transformation keyword argument is from #13458, which is listed as a dependency

Very sorry: I'm sure when I looked all three had the line through (I cannot see the colours very well).
Testing again, with your new revision...

[JohnCremona]

comment:78

I'm now happy to give this a positive review -- at last! Thanks to Volker for the hard work which gives a lot more than this ticket originally promised.

I do not feel qualified to positively review #13458 though, so I hope this is not being inconsistent of me.

[jdemeyer]

comment:80

Sorry, there are some issues with these patches:

Most importantly, the doctests for Jacobian_magma_from_plane_curve don't actually use the function Jacobian_magma_from_plane_curve. So the function which is "useful for doctesting" doesn't seem to be used in any doctest.

Then some details: I would replace

sage: x,y,z=PolynomialRing(QQ,3,'xyz').gens()

by

sage: R.<x,y,z> = PolynomialRing(QQ,3)

or

sage: R.<x,y,z> = QQ[]

And also replace

sage: f = x**5 + 1184*x**3 + 1846*x**2 + 956*x + 560

by

sage: f = x^5 + 1184*x^3 + 1846*x^2 + 956*x + 560

[vbraun]

comment:81

I didn't write the Jacobian_magma_... functions, for the record. I just moved it out of constructor.py into a less visible location. I don't think that beautifying them makes any sense, the docstring is pretty clear that you shouldn't base your work on it. If anything, it should be removed altogether. Though IMHO that is not particularly urgent.

The attached patch changes the function call so that it is doctested.

[jdemeyer]

comment:83

Can any of the "official" reviewers of this ticket please check that these doctests pass with magma with

./sage -t --optional=sage,magma devel/sage/sage/schemes/elliptic_curves

[JohnCremona]

comment:84

Replying to @jdemeyer:

Can any of the "official" reviewers of this ticket please check that these doctests pass with magma with

./sage -t --optional=sage,magma devel/sage/sage/schemes/elliptic_curves

I just did, and there are some problems, which I am now fixing.

I note that the dependent #13458 is marged as having been merged, but only in 5.12.beta0 which is in the future for most of us!

John

[JohnCremona]

comment:85

Am I doing something stupid here? I have 5.11.rc0 with the patches from #13458 and this ticket applied. Now

sage: R.<x,y,z> = QQ[]
sage: f = x^3+y^3+60*z^3                            
sage: from sage.schemes.elliptic_curves.jacobian import Jacobian_magma_equation
sage: E = Jacobian_magma_equation(f)
(...)
NameError: global name 'SR' is not defined

despite

sage: SR
Symbolic Ring

The relevant line works fine by itself:

sage: cmd = "P<%s,%s,%s> := ProjectivePlane(RationalField());"%SR(f).variables()
sage: cmd
'P<x,y,z> := ProjectivePlane(RationalField());'

[vbraun]

comment:86

I've added the missing import, should work now.

[JohnCremona]

comment:87

Replying to @vbraun:

I've added the missing import, should work now.

That's odd as I would not have expected it to be necessary to import SR for a doctest.

Anyway, that function is still wrong since 2 lines later it refers to P which I presume is a point on the curve, but there is no parameter P. Shall we just delete this completely redundant function?

The next function Jacobian_magma_from_plane_curve needs a minor fix in the last line since rings is not imported. It's fine with

    from sage.rings.all import QQ
    return EllipticCurve(QQ, eval(s))

[vbraun]

Attachment: trac_3416_magma.patch.gz

Updated patch

[vbraun]

comment:88

Updated patch removes both Jacobian_magma_... functions since they don't really add anything useful.

[JohnCremona]

comment:89

Replying to @vbraun:

Updated patch removes both Jacobian_magma_... functions since they don't really add anything useful.

Now the optional tests certainly pass! Back to positive review, and I hope that Jeroen is happy.

[jdemeyer]

comment:90

Replying to @JohnCremona:

Replying to @vbraun:

Updated patch removes both Jacobian_magma_... functions since they don't really add anything useful.

Now the optional tests certainly pass!

Obviously :-)

I hope that Jeroen is happy.

Sure!

[jdemeyer]

Merged: sage-5.12.beta3

[vbraun]

comment:92

See #15340 for a follow-up.