possible clash for EllipticCurve(j-invariant) signature

[nbruin]

Since Elliptic curves should probably have some things in common, one would probably at some point want signatures of the type

EllipticCurve(f) and EllipticCurve(f,h)

to define curves with models y^2=f(x) and y^2+h(x)*y=f(x).
This would clash with EllipticCurve(j-invariant) that exists now.

Example:

EllipticCurve(x^3-x)

Should this create an elliptic curve over Q[x] with j-invariant x^3-x or should it create an elliptic curve over Q with equation y<sup>2=x</sup>3-x?

Magma did go with the first for a while but decided to stick with the latter later.

CC: @JohnCremona @jdemeyer

Component: elliptic curves

Reviewer: Paul Zimmermann, Nils Bruin, John Cremona

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

[sagetrac-mabshoff]

Description changed:

--- 
+++ 
@@ -1,14 +1,16 @@
 Since Elliptic curves should probably have some things in common, one would probably at some point want signatures of the type
 
+```
 EllipticCurve(f) and EllipticCurve(f,h)
-
-to define curves with models y^2=f(x) and y^2+h(x)*y=f(x).
+```
+to define curves with models `y^2=f(x)` and `y^2+h(x)*y=f(x)`.
 This would clash with EllipticCurve(j-invariant) that exists now.
 
 Example:
 
+```
 EllipticCurve(x^3-x)
-
-Should this create an elliptic curve over Q[x] with j-invariant x^3-x or should it create an elliptic curve over Q with equation y<sup>2=x</sup>3-x?
+```
+Should this create an elliptic curve over Q[x] with j-invariant `x^3-x` or should it create an elliptic curve over Q with equation `y<sup>2=x</sup>3-x`?
 
 Magma did go with the first for a while but decided to stick with the latter later.

[sagetrac-mabshoff]

comment:3

Is this still an issue? I have added John to the CC field since he is the resident expert ;).

John: Do you have an opinion on this? Feel free to ignore this if you have more pressing things to tend to.

Cheers,

Michael

[JohnCremona]

comment:4

It is still an issue in the sense that nothing has changed:

sage: R.<x>=QQ[]
sage: E=EllipticCurve(x^3+1)
sage: E
Elliptic Curve defined by y^2  = x^3 + (-3*x^6+5178*x^3+5181)*x + (-2*x^9+6906*x^6-5958150*x^3-5965058) over Fraction Field of Univariate Polynomial Ring in x over Rational Field
sage: E.j_invariant()
x^3 + 1

Personally I would not want the EllipticCurve() function to do something totally different if passed one thing which happened to be a polynomial (or a pair of polynomials) -- but then I just don't think of elliptic curves as being defined by polynomials.

Note that this does work:

sage: H.genus()
1
sage: R.<x>=QQ[]
sage: H=HyperellipticCurve(x^3+1)
sage: H
Hyperelliptic Curve over Rational Field defined by y^2 = x^3 + 1
sage: H.genus()
1
sage: H.hyperelliptic_polynomials()
(x^3 + 1, 0)

and the HyperellipticCurve() function only takes a polynomial (or two) as inputs, something which I would not suggest changing.

Hence it might be reasonable to proceed as follows. Keep the existing facility for defining a HyperellipticCurve of genus 1 out of two polynomials, and define a new constructor EllipticCurve() which takes a HyperellipticCurve H (of genus 1 of course) as input. This would require that the first of H.hyperelliptic_polynomials() was monic and degree 3, and that the second had degree at most 1, otherwise an exception would be raised.

If this was implemented then at least this would work:

E=EllipticCurve(HyperellipticCurve(x^3+1,x+1))

and result in the elliptic curve y^2+x*y+y=x3+1.

Is Nils receiving this? Does he have an opinion?

[nbruin]

comment:5

First of all, sorry for the typo in the original report. I meant "in common with hyperelliptic curves". Subsequent commentary is consistent with that. The idea is that "elliptic curves in Weierstrass form" can be viewed as a subcategory of "double covers of P^1" that hyperelliptic curves in computer algebra seem to symbolize, and hence that everything that works for hyperelliptic curves should work for elliptic curves as well.

I do think of (models of) elliptic curves as being defined by polynomials, so for me the proposed signatures EllipticCurve(f) and EllipticCurve(f,h) feel very natural. Sage itself agrees:

sage: EllipticCurve(1)
Elliptic Curve defined by y^2  = x^3 + 5181*x - 5965058 over Rational Field

The way the curve is printed seems to indicate that the curve is indeed defined by a polynomial (apart from the "y^2=" bit).

The signature EllipticCurve(HyperellipticCurve(..)) should indeed work at some point as well, which makes me think that the design decisions made here should be looked at in the broader setting of how algebraic geometry constructions will work in sage. Ultimately, sage is going to have to be able to have functions of the type

make_elliptic_curve_from(cubic, rational point)
make_elliptic_curve_from(singular plane quartic, rational point)
make_elliptic_curve_from(genus 1 curve, degree 1 divisor)
give_jacobian_as_elliptic_curve(genus 1 curve)

Most of these (and also the make_elliptic_curve(hyperelliptic curve) signature) should be able to return a birational map. Since those maps are not canonical to neither the curve nor the elliptic curve, we can't really handle those maps via the coercion system, so the magmatic solution of returning the map as a second value seems most natural to me.

I'm not sure if some of those should be overloaded into the EllipticCurve constructor (I would like that, because it's what I'm used to in magma. Constructors in sage seem to be very lenient in what they accept as input anyway)

The relevance for this report:

If the EllipticCurve constructor is going to be rather liberal in what it accepts for input, then I think people will expect it can take defining polynomials as well, and they won't expect an elliptic curve that happens to have a j-invariant equal to that polynomial as a return value.

I agree with John that EllipticCurve() should behave differently depending on the type of ring that is put in. Given that in most cases the j-invariant does -not- determine uniquely an elliptic curve over the ring the j-invariant lives in, I think that the section map of

->

should not be used as a valid default constructor for EllipticCurve. Instead have a function elliptic_curve_from_j_invariant, or some more palatable name. However, that's just my opinion. David Kohel's opinion would be interesting here as well.

[nbruin]

comment:6

Sorry about yet another typo. I agree with John and hence think that EllipticCurve() should NOT behave differently based on the ring type. Would
EllipticCurve(j=1728)
do the trick for people? Is it even acceptable to have a constructor that is happy with no unnamed parameters?

[JohnCremona]

comment:7

Having thought about it, I now agree with Nils: sine there is not a unique E.C. with given j-invariant, having a constructor of E from j -- which necessarily therefore makes an arbitray choice -- is not very sensible.

So we should instead have a function called something like EllipticCurve_from_j(j) which does the same as the current EllipticCurve(j), and this frees up a role for a 1-parameter constructor where the parameter is a polynomial. But it still makes constructing a curve from a pair of polynomials problematical (since currently EllipticCurve(a,b) is the same as EllipticCurve([0,0,0,a,b]).

Nile is also quite right that in due course we should have a lot more ways of constructing E.C.s from other things.

[JohnCremona]

comment:8

See the related #5673

[chriswuthrich]

comment:9

I think this ticket should be closed. The issue is solved by #5673.

[JohnCremona]

comment:10

We still do not have a constructor from a monic cubic in one variable (or a cubic and a linear). That would be quite easy, though it would have to have a new name (e.g. elliptic_curve_from_polynomials(f,g)) since otherwise it would conflict with other constructors using EllipticCurve().

Speaking personally I would be happy to close this though!

[JohnCremona]

Attachment: trac_128-ec-constructor.patch.gz

Applies to 4.3.rc0