Opened 9 years ago

Closed 9 years ago

#15737 closed defect (fixed)

Problem in an_padic

Reported by: wuthrich Owned by:
Priority: major Milestone: sage-6.2
Component: elliptic curves Keywords: padic l-functions
Cc: Merged in:
Authors: Chris Wuthrich Reviewers: Peter Bruin
Report Upstream: N/A Work issues:
Branch: 029c472 (Commits, GitHub, GitLab) Commit: 029c472cb167507ab515507b56baa7f7cddac313
Dependencies: Stopgaps:

Status badges

Description (last modified by wuthrich)

The following produces a error

E = EllipticCurve([-100,0])
s = E.sha()

The error comes from the an_padic asking for only the first constant coefficient of the p-adic L-series. 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 wuthrich

Authors: Chris Wuthrich
Branch: u/wuthrich/ticket/15737
Commit: afe228dbcd688562d4aed0872376af918f67c023
Description: modified (diff)
Keywords: padic l-functions added
Status: newneeds_review

I fixed a few Error syntaxes, too

New commits:

afe228dTrac #15737: Error relating to precision in sha_tate

comment:2 Changed 9 years ago by For batch modifications

Milestone: sage-6.1sage-6.2

comment:3 Changed 9 years ago by Peter Bruin

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/

    diff --git a/src/sage/schemes/elliptic_curves/ b/src/sage/schemes/elliptic_curves/
    index c964189..ced0472 100644
    a b class pAdicLseriesOrdinary(pAdicLseries): 
    882882            print 'Warning : For p=2 the normalization might not be correct !'
    883883        #verbose("computing L-series for p=%s, n=%s, and prec=%s"%(p,n,prec))
    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
    887890        verbose("using p-adic precision of %s"%padic_prec)
    889892        res_series_prec = min(p**(n-1), 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 wuthrich

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 Peter Bruin

I don't know enough about p-adic L-series, but why exactly is prec=1 a meaningless argument? It should give you precisely enough information to get the 0-th coefficient. (If I understand correctly, prec is not the p-adic precision, but the power series precision; it does influence the p-adic 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 wuthrich

Status: needs_reviewneeds_work

The constant term of the p-adic L-function 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 no-one should want to compute the constant term with a p-adic L-function 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 wuthrich

Branch: u/wuthrich/ticket/15737u/wuthrich/ticket/15737_new
Commit: afe228dbcd688562d4aed0872376af918f67c023a4982cd0c4b5a47efc064ac11f3709fbf0841b16
Status: needs_workneeds_review


New commits:

06a926eTrac #15737: Error relating to precision in sha_tate
eea1256Trac 15737: adjusting the ordinary case
a4982cdTrac 15737: fixing the supersingular case, too

comment:8 Changed 9 years ago by Peter Bruin

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 git

Commit: a4982cd0c4b5a47efc064ac11f3709fbf0841b16029c472cb167507ab515507b56baa7f7cddac313

Branch pushed to git repo; I updated commit sha1. New commits:

029c472Trac 15737: small correction

comment:10 Changed 9 years ago by wuthrich

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 Peter Bruin

Reviewers: Peter Bruin
Status: needs_reviewpositive_review

OK, I'm happy now and all tests pass.

comment:12 Changed 9 years ago by Volker Braun

Branch: u/wuthrich/ticket/15737_new029c472cb167507ab515507b56baa7f7cddac313
Resolution: fixed
Status: positive_reviewclosed
Note: See TracTickets for help on using tickets.