Opened 9 years ago
Closed 9 years ago
#15737 closed defect (fixed)
Problem in an_padic
Reported by:  wuthrich  Owned by:  

Priority:  major  Milestone:  sage6.2 
Component:  elliptic curves  Keywords:  padic lfunctions 
Cc:  Merged in:  
Authors:  Chris Wuthrich  Reviewers:  Peter Bruin 
Report Upstream:  N/A  Work issues:  
Branch:  029c472 (Commits, GitHub, GitLab)  Commit:  029c472cb167507ab515507b56baa7f7cddac313 
Dependencies:  Stopgaps: 
Description (last modified by )
The following produces a error
E = EllipticCurve([100,0]) s = E.sha() s.an_padic(13)
The error comes from the an_padic asking for only the first constant coefficient of the padic Lseries. But it does not harm to compute the next one too. (This arises only when a twist is involved, otherwise the the modular symbol at 0 is called directly.)
Change History (12)
comment:1 Changed 9 years ago by
Authors:  → Chris Wuthrich 

Branch:  → u/wuthrich/ticket/15737 
Commit:  → afe228dbcd688562d4aed0872376af918f67c023 
Description:  modified (diff) 
Keywords:  padic lfunctions added 
Status:  new → needs_review 
comment:2 Changed 9 years ago by
Milestone:  sage6.1 → sage6.2 

comment:3 Changed 9 years ago by
Would it be possible to solve the problem instead by fixing the series
method of pAdicLSeriesOrdinary
, and similarly of pAdicLSeriesSupersingular
, rather than the call to it? I mean something like this:

src/sage/schemes/elliptic_curves/padic_lseries.py
diff git a/src/sage/schemes/elliptic_curves/padic_lseries.py b/src/sage/schemes/elliptic_curves/padic_lseries.py index c964189..ced0472 100644
a b class pAdicLseriesOrdinary(pAdicLseries): 882 882 print 'Warning : For p=2 the normalization might not be correct !' 883 883 #verbose("computing Lseries for p=%s, n=%s, and prec=%s"%(p,n,prec)) 884 884 885 bounds = self._prec_bounds(n,prec) 886 padic_prec = max(bounds[1:]) + 5 885 if prec <= 1: 886 padic_prec = 5 887 else: 888 bounds = self._prec_bounds(n, prec) 889 padic_prec = max(bounds[1:]) + 5 887 890 verbose("using padic precision of %s"%padic_prec) 888 891 889 892 res_series_prec = min(p**(n1), prec)
This would also make the following work:
sage: Et=EllipticCurve([1,0]) sage: lp=Et.padic_lseries(13) sage: lp.series(3, prec=1) 6 + 12*13 + O(13^3) + O(T)
comment:4 Changed 9 years ago by
Hmmm. That would work as well indeed. However I have a slight preference for my solution, because I think a) giving an insufficient precision should raise an error rather than setting it arbitrarily to 5 and b) the call from sha an_padic
should do the right thing independently of what padic_lseries
would do with a meaningless argument.
But if you see a reason for doing a) your way, I have nothing against changing it.
comment:5 Changed 9 years ago by
I don't know enough about padic Lseries, but why exactly is prec=1
a meaningless argument? It should give you precisely enough information to get the 0th coefficient. (If I understand correctly, prec
is not the padic precision, but the power series precision; it does influence the padic working precision.) Am I correct that it would make sense for series()
to return the same result for prec=1
as for prec=2
but with the series truncated to O(T^1)
?
Setting padic_prec=5
in the case prec=1
, as in my above comment, is probably indeed a mistake; it seemed a reasonable extrapolation from the formula padic_prec = max(bounds[1:]) + 5
used for prec >= 2
.
comment:6 Changed 9 years ago by
Status:  needs_review → needs_work 

The constant term of the padic Lfunction is a multiple of m(0)=L(E,1)/Omega where m is the modular symbol attached to E. Whatever n is, the constant term is always correct (up to the precision with which alpha was computed). So in some sense noone should want to compute the constant term with a padic Lfunction as one can do it without.
But I think prec=1 could be a acceptable entry and then we should return just the constant term (as a powerseries with O(T) ) but avoiding all summation computations. Then I can go back to sha and leave it as it was. That would be a better solution, not only fixing the bug, but also improving the code.
I will try to do this over the next days.
comment:7 Changed 9 years ago by
Branch:  u/wuthrich/ticket/15737 → u/wuthrich/ticket/15737_new 

Commit:  afe228dbcd688562d4aed0872376af918f67c023 → a4982cd0c4b5a47efc064ac11f3709fbf0841b16 
Status:  needs_work → needs_review 
comment:8 Changed 9 years ago by
Looks good, just one more small thing: in the case where E is supersingular at p, prec=1
and eta != 0
, you have the line
padic_prec = [[20,20]]
(the padic_prec
is simply 20 in the analogous ordinary case.)
Is this correct? It seems to cause errors of the following kind:
sage: E = EllipticCurve("17a1") sage: L = E.padic_lseries(3) sage: L.series(4,prec=1,eta=1) ... TypeError: unable to coerce <type 'list'> to an integer
comment:9 Changed 9 years ago by
Commit:  a4982cd0c4b5a47efc064ac11f3709fbf0841b16 → 029c472cb167507ab515507b56baa7f7cddac313 

Branch pushed to git repo; I updated commit sha1. New commits:
029c472  Trac 15737: small correction

comment:10 Changed 9 years ago by
Absolutely right. I thought I checked all cases, but I did not. Sloppy of my part. Thanks for pointing this out.
comment:11 Changed 9 years ago by
Reviewers:  → Peter Bruin 

Status:  needs_review → positive_review 
OK, I'm happy now and all tests pass.
comment:12 Changed 9 years ago by
Branch:  u/wuthrich/ticket/15737_new → 029c472cb167507ab515507b56baa7f7cddac313 

Resolution:  → fixed 
Status:  positive_review → closed 
I fixed a few Error syntaxes, too
New commits:
Trac #15737: Error relating to precision in sha_tate