It's easy to check whether two curves are equal: just check that
E1.base_ring() equals E2.base_ring() (these are usually both fields
but can also be rings) and then that E1.a_invariants() =
E2.a_invariants(): these are immutable tuples of 5 elements of the
> You received this message because you are subscribed to the Google Groups "sage-nt" group.
> To post to this group, send an email to sag...@googlegroups.com.
> To unsubscribe from this group, send email to sage-nt+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sage-nt?hl=en-GB.
Correct -- in fact usually the a-invariants are the input parameters
for the constructor.
> OK, if you agree that it's a bug then I'll open a ticket tomorrow
On Tue, Jun 14, 2011 at 10:25 AM, Simon King <simon...@uni-jena.de> wrote:
> Hi John,
> I have one question about your database.
> In ell_rational_field, I see that attributes such as 'rank',
> 'torsion_order', 'cremona_label', 'conductor', 'modular_degree',
> 'gens', 'regulator' are taken from your data base. But in
> ell_number_field, only the a-invariants are taken from the database.
My database has no curves over number fields other than Q.
> Are those attributes not contained in your database, for number
> fields? Is there a chance that they will ever be? Is it planned to
> extend your database by further attributes?
William has a project to make a database for one field, Q(sqrt(5)).
But there will be no large-scale complete databases over general
number fields for a long time.
I don't see how the code below could ever be executed.
Note that Elliptic Curves are normally constructed by the top-level
function EllipticCurve(args) -- found in
elliptic_curves/constructor.py -- which works hard to decipher what
the args might mean and then call the appropriate init function of the
appropriate class. If the args are a string then the the string is
assumed to be a label in my database and the following is executed:
if isinstance(x, str):
so there is never a situation where a string is passed to the
constructor of EllipticCurve_number_field. I guess that might change
in teh future, but as of right now there is no agreed labelling of
elliptic curves by strings except over Q.
I hope this helps.
> I see. But the a-invariants can (apparently) be taken from it anyway?
> Because it says in ell_number_field.py:
> if isinstance(y, str):
> field = x
> X = sage.databases.cremona.CremonaDatabase()[y]
> ainvs = Sequence(X.a_invariants(), universe=field,
> field = x
> ainvs = Sequence(y, universe=field, immutable=True)
> Then, I think I know what to do in order to make them unique parents,
> using UniqueRepresentation. I hope I'll have time later today.
As elliptic curves over Q are currently implemented one would have to
try quite hard to construct a curve with generators which are not the
ones in the database (E.gens() has a parameter use_database which is
True by default). But this *is* possible and we need to deal with it.
Perhaps Simon's suggestion is a good one: E is F is False if E, F are
the same curve (identical a-invariants) but have some other attributes
which disagree then they should be deemed to be different.
I very much like Nils's (very Magma-like) idea to have the
Mordell-Weil group of the curve as a separate object which is an
abstract abelian group with a map to the point-set. It used to be the
case that the abelian group infrastructure was not good enough to make
that work at all pleasantly, but now I think it is. In fact we
already have something like this for the torsion subgroup:
sage: E = EllipticCurve('14a1')
sage: T = E.torsion_subgroup()
+ a b c d e f
a| a b c d e f
b| b c d e f a
c| c d e f a b
d| d e f a b c
e| e f a b c d
f| f a b c d e
and for the group of points over finite fields:
sage: E = EllipticCurve(GF(11),[2,2])
sage: A = E.abelian_group()
[(0 : 1 : 0), (1 : 4 : 1), (2 : 5 : 1), (9 : 10 : 1), (5 : 4 : 1), (5
: 7 : 1), (9 : 1 : 1), (2 : 6 : 1), (1 : 7 : 1)]
but it is only "something like" since the abstract group "knows" that
its elements are "really" points on the curve, without having to
explicitly map them to the curve as in Magma.
> Nils always convinces me, and I have been too busy recently to think
> this through very carefully.
> I very much like Nils's (very Magma-like) idea to have the
> Mordell-Weil group of the curve as a separate object which is an
> abstract abelian group with a map to the point-set.
Pretty much. Though it's not really like (say) for vector spaces and
modules where one might choose to use different generating sets for
different reasons; it's more that finding both the abstract group
structure and any set of generators is pretty hard! That's one reason
why the database has generators, to save the (sometimes great) time
needed to find them. In fact, even over Q there is no algorithm
known even in principal, let alone implemented, which is guaranteed to
always find generators. (The "even in principle" above is related to
unsolved problems surrounding the Birch & Swinnerton-Dyer conjectures,
such as the finiteness of the Tate-Shafarevich group).
For this reason there are times when (say) one cannot prove that the
rank is 1, only that it is either 1 or 3, and one has 1 generator, and
want to store that; or you may know that the rank is at most 2, but
only have one generator, suspect that there is a second one (whose
very existence is based on BSD!) but cannot find it. And so on.
That's the way elliptic curves work....
By the way, all the above is only relevant for elliptic curves over
number fields (including Q) [and other global fields but there's
nothing in Sage about other sorts yet) so the right place to attach a
MordellWeilGroup structure would be to elliptic_curve_number_field.
> Let E be an elliptic curve over a number field K.
> Current behaviour is that E.gens() (if it succeeds) returns generators
> for the Mordell-Weil group of E, i.e., the K-rational points on E. One
> may want to work with different generating sets, and they may change
> over time, and the choice of generators has a big impact on various
> algorithms. Therefore my idea of turning E into a unique parent (and
> thus caching gens()) is a bad idea.
> However, a cleaner (or Magma-like) approach would be to distinguish
> between the elliptic curve and the Mordell-Weil group. Hence, E.gens()
> should be eliminated, and there should be a new method
> E.mordell_weil() returning the Mordell-Weil group MW of E. MW should
> be an abstract group, but with the possibility to simultaneously
> define several sets of generators.
> Then, E could indeed be a unique parent structure (namely E is F if
> and only if E==F if and only if E.base_ring()==F.base_ring() and
> E.ainvs()==F.ainvs()). And for the Mordell-Weil group, some
> infrastructure from the combinat folks should be applied, since they
> can deal with abstract objects that simultaneously have different
> bases or sets of generators, IIRC.
> But what does that make of #11474? Should it be closed? Should I add
> my patch (making E unique), although it leaves a lot of doctest
I'll have to take a look at that; I don't know what sort of failures tehre are.