#11271: there is a serious bug in the documentation or code for is_surjective
for
Galois representations attached to elliptic curves
-------------------------------+--------------------------------------------
Reporter: was | Owner: cremona
Type: defect | Status: new
Priority: critical | Milestone: sage-4.7.1
Component: elliptic curves | Keywords:
Work_issues: | Upstream: N/A
Reviewer: | Author:
Merged: | Dependencies:
-------------------------------+--------------------------------------------
David Zywina pointed out to me that the docstring for the Sage function
clearly states: "Return True if the mod-p representation is surjective
onto Aut(E[p])=GL2(Fp). False if it is not, or None if we were unable to
determine whether it is or not."
So according to the docstring, if the functions returns either True or
False, then it returns the right answer. The documentations suggests that
if the function returns None (which is completely different than
True/False in Python), then you have to re-call it with a bigger
parameter. That said, I just looked through the actual source code, and
this simply isn't true at all!
{{{
sage: E = EllipticCurve('147b1')
sage: rho = E.galois_representation()
sage: rho._is_surjective??
...
while ell < A:
ell = arith.next_prime(ell)
if Np % ell != 0:
...
return False #, signs
}}}
That "return False" at the end should be "return None" according to the
docstring. So this is a serious bug in the Sage documentation or in the
function. The options for a fix are:
1. Probably the function as is can never ever prove non-surjectivity,
except in various special cases. It should be changed to a better one
that can prove non-surjectivity maybe following [1], or at least using
division polynomials (since p<=37 anyways).
2. Change the lying docstring a lot to agree with the code. NOTE: One
should probably also change the docstring for the deprecated
"E.is_surjective()" which is also misleading.
[1] http://www.math.upenn.edu/~zywina/papers/EffectiveModl.pdf
I could imagine doing 2 above quickly, then opening another ticket for 1,
or even having 1 as part of #11270 later.
I'm marking this as "critical" since it is a major misleading mathematical
bug, and it is functionality that gets used as a hypothesis for
computational papers a lot (though in practice always in the direction
that is safe, but who knows?).
See also: #11270
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11271>
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.
