#8945: Cremona labels messed up
-----------------------------+----------------------------------------------
Reporter: davidloeffler | Owner: craigcitro
Type: defect | Status: new
Priority: major | Milestone: sage-5.0
Component: modular forms | Keywords:
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
-----------------------------+----------------------------------------------
Comment(by davidloeffler):
It looks like eclib supports two different sorting conventions: the "old"
convention where curves are sorted first by their local root numbers at
the bad primes, and then by their a_p's in the order 0,1,-1,2,-2,..., and
the "new" convention which is a straight numerical sort on the a_p's.
The "old" eclib order (with ad-hoc modifications for 46 <= N <= 450) seems
to be what's used in the tables supplied with Sage, and hence it's what
the {{{EllipticCurve('225a1')}}} constructor picks up. The "new" eclib
order seems to be what Sage is using. So the two really are different for
infinitely many N (the permutation for N = 9999 seems to be [3, 6, 0, 8,
5, 11, 10, 9, 4, 2, 7, 1, 12]).
We could change Sage's system to correspond to eclib's old one, but that
would only really work for Gamma0(N), since I don't know a good way of
calculating the local root numbers in general -- we'd probably have to
keep the old sort order for Gamma1 and GammaH spaces and spaces with
character.
Maybe it's best to not attempt to fix this issue, and to live with the
fact that the conventions don't necessarily agree.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/8945#comment:2>
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.
