Opened 8 years ago

Closed 8 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 8 years ago by wuthrich

  • Authors set to Chris Wuthrich
  • Branch set to u/wuthrich/ticket/15737
  • Commit set to afe228dbcd688562d4aed0872376af918f67c023
  • Description modified (diff)
  • Keywords padic l-functions added
  • Status changed from new to needs_review

I fixed a few Error syntaxes, too

New commits:

afe228dTrac #15737: Error relating to precision in sha_tate

comment:2 Changed 8 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:3 Changed 8 years ago by pbruin

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 8 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 8 years ago by pbruin

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 8 years ago by wuthrich

  • Status changed from needs_review to needs_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 8 years ago by wuthrich

  • Branch changed from u/wuthrich/ticket/15737 to u/wuthrich/ticket/15737_new
  • Commit changed from afe228dbcd688562d4aed0872376af918f67c023 to a4982cd0c4b5a47efc064ac11f3709fbf0841b16
  • Status changed from needs_work to needs_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 8 years ago by pbruin

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 8 years ago by git

  • Commit changed from a4982cd0c4b5a47efc064ac11f3709fbf0841b16 to 029c472cb167507ab515507b56baa7f7cddac313

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

029c472Trac 15737: small correction

comment:10 Changed 8 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 8 years ago by pbruin

  • Reviewers set to Peter Bruin
  • Status changed from needs_review to positive_review

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

comment:12 Changed 8 years ago by vbraun

  • Branch changed from u/wuthrich/ticket/15737_new to 029c472cb167507ab515507b56baa7f7cddac313
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.