Opened 4 years ago

Closed 3 years ago

#26098 closed enhancement (fixed)

Implement L-functions using the PARI library

Reported by: Frédéric Chapoton Owned by:
Priority: major Milestone: sage-8.9
Component: number theory Keywords: dokchitser, lseries, zeta
Cc: John Cremona, David Lowry-Duda Merged in:
Authors: Frédéric Chapoton Reviewers: Travis Scrimshaw
Report Upstream: N/A Work issues:
Branch: 091f71b (Commits, GitHub, GitLab) Commit: 091f71b6100ec912d2e28c451ff87231abeee1e9
Dependencies: Stopgaps:

Status badges

Change History (104)

comment:1 Changed 4 years ago by Frédéric Chapoton

Branch: public/26098
Keywords: dokchitser added

comment:2 Changed 4 years ago by git

Commit: f53b6432cedcdf76e3adfe2f30c5fdf679d95e46

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

f53b643tentative to use the Dokchitser setting from pari itself..

comment:3 Changed 4 years ago by Frédéric Chapoton

Description: modified (diff)

comment:4 Changed 4 years ago by git

Commit: f53b6432cedcdf76e3adfe2f30c5fdf679d95e46e985afcebe6d3747d9a7f7c8e9705ca7edc55e2e

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

e985afcadding the Lambda function

comment:5 Changed 4 years ago by Jeroen Demeyer

Good idea! It's something that I always wanted to do but never found the time...

Some immediate comments:

  1. Regarding
    """
    Dokchitser's L-functions Calculator from Pari
    
    AUTHORS:
    
    - Tim Dokchitser (2002): original PARI code and algorithm (and the
      documentation below is based on Dokchitser's docs).
    
    - William Stein (2006-03-08): Sage interface
    
    """
    

To what extent is this related to code from Dokchitser or Stein? If the answer is "not at all", then the author block, the copyright block, the name of the module and the name of the class Dokchitser_Pari should be fixed.

  1. Assigning self.pari = Pari() looks strange as there is really one PARI running. Better be honest about that and use a single global pari variable (you can import it from sage.libs.pari).
  1. self.pari('default(realprecision, %s)') is a bad idea for multiple reasons. The proper way to deal with precisions in library mode is either to set the precision argument for every function call or to use inexact inputs.
  1. Avoid using global PARI variables like in the pari_precode example tau(n)=.... Remember that there is only one global PARI instance, so global variables are global state! If you want functions, why not use actual functions (using the -> syntax)?

comment:6 Changed 4 years ago by git

Commit: e985afcebe6d3747d9a7f7c8e9705ca7edc55e2e4f159376a18570e8af12fab21bd88de0fee07130

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

4f15937work on Lfunction direct interface to Pari lfun

comment:7 Changed 4 years ago by git

Commit: 4f159376a18570e8af12fab21bd88de0fee07130c48fb4ba457b1c750f496374b4a154d59052c8b0

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

c48fb4btrac 26098 plug into elliptic curves

comment:8 Changed 4 years ago by git

Commit: c48fb4ba457b1c750f496374b4a154d59052c8b0a364f56563638ce2fbcd617da8218b9e97099964

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

a364f56details on 26098

comment:9 Changed 4 years ago by Jeroen Demeyer

Some more comments:

  1. You can replace pari.FUNCTION(pari(FOO)) by pari.FUNCTION(FOO).
  1. It is still not clear to me why you keeping using "dokchitser" (I may be missing something, but then it should be clarified)
  1. Using the .sage() method is often not the best way to convert a PARI object to Sage because you loose information about the parent. For example:
    sage: x = RR.pi()
    sage: parix = pari(x)
    sage: parent(parix.sage())
    Real Field with 64 bits of precision
    

It would be better to replace parix.sage() by RR(parix) in this case.

comment:10 in reply to:  9 ; Changed 4 years ago by Frédéric Chapoton

Replying to jdemeyer:

Some more comments:

  1. You can replace pari.FUNCTION(pari(FOO)) by pari.FUNCTION(FOO).

will do

  1. It is still not clear to me why you keeping using "dokchitser" (I may be missing something, but then it should be clarified)

There are Dokchitser's algorithms (described in a famous article in Experimental Math) and Dokchitser's implementation of them (that we use so far). Pari is using (maybe an enhanced version of) the algorithms of Dokchitser or at least similar basic ideas.

comment:11 Changed 4 years ago by git

Commit: a364f56563638ce2fbcd617da8218b9e9709996468b4d8f04a20c91104454be1fa3e952b6e302578

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

68b4d8ftrying to add Dirichlet L-functions

comment:12 Changed 4 years ago by git

Commit: 68b4d8f04a20c91104454be1fa3e952b6e302578574c147ca7a45854b3ae26f3fc4a8cb334744a3b

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

574c147trac 26098 adding the derivative

comment:13 Changed 4 years ago by Frédéric Chapoton

Description: modified (diff)

New commits:

574c147trac 26098 adding the derivative

comment:14 in reply to:  10 Changed 4 years ago by Jeroen Demeyer

Replying to chapoton:

Pari is using (maybe an enhanced version of) the algorithms of Dokchitser or at least similar basic ideas.

I don't think that is sufficient reason to use the name "Dokchitser". Personally, I think it is especially confusing because we also have Dokchitser's GP scripts (where he is the actual author). I would rather name the module lfunctions_pari.py or something along those lines.

comment:15 Changed 4 years ago by Frédéric Chapoton

Branch: public/26098u/chapoton/26098
Cc: John Cremona added
Commit: 574c147ca7a45854b3ae26f3fc4a8cb334744a3b0fc42d265d744fc0cc8ea4d5c7dbe9e5a9e0d67f

here is a new branch, with squashed commits

What is still lacking is a correct handling of precision

To people of lmfdb, is this something of interest for you ?


New commits:

0fc42d2trac 26098 interface for the L-functions setting of Pari

comment:16 Changed 4 years ago by git

Commit: 0fc42d265d744fc0cc8ea4d5c7dbe9e5a9e0d67fff9bef13851a57f2c2be5a29b2b40f4dec79ee24

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

ff9bef1trac 26098 fixing some doctests

comment:17 Changed 4 years ago by git

Commit: ff9bef13851a57f2c2be5a29b2b40f4dec79ee2496aa04d08c21c75e390808c9e9d6c47f8eb64ad7

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

96aa04dtrac 26098 interface for the L-functions setting of Pari

comment:18 Changed 4 years ago by git

Commit: 96aa04d08c21c75e390808c9e9d6c47f8eb64ad78efdaf7702c14ed1761ceb42f11c6700f35aba86

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

8efdaf7trac 26098 interface for the L-functions setting of Pari

comment:19 Changed 4 years ago by Jeroen Demeyer

Description: modified (diff)
Summary: using Dokchitser setting direct from pariImplement L-functions using the PARI library

comment:20 in reply to:  15 Changed 4 years ago by Jeroen Demeyer

Replying to chapoton:

What is still lacking is a correct handling of precision

Every function where precision matters takes a precision argument. For example

sage: pari(1).sin(precision=64).sage()
0.841470984807896507
sage: pari(1).sin(precision=256).sage()
0.8414709848078965066525023216302989996225630607983710656727517099919104043912

comment:21 Changed 4 years ago by Jeroen Demeyer

It would be nice to support calling lfuncreate in LFunction.__init__. Something like

        if isinstance(lfun, lfun_generic):
            # preparation using Dokchitser data
            self._L = lfun.lfun()
        elif isinstance(lfun, Gen):
            # already some Pari lfun
            self._L = lfun
        else:
            # create a PARI lfunction from input data
            self._L = pari.lfuncreate(lfun)

This would remove the need for lfun_elliptic_curve() and lfun_number_field().

comment:22 Changed 4 years ago by Jeroen Demeyer

Note that PARI functions also act as methods. So you could replace

pari.lfun(self._L, s)

by the simpler

self._L.lfun(s)

comment:23 Changed 4 years ago by Frédéric Chapoton

Concerning precision, this is not so easy..

sage: from sage.lfunctions.lfunctions_pari import *
sage: lf = lfun_number_field(QQ)
sage: pari.lfun(lf, 2)
1.64493406684823
sage: pari.lfun(lf, 2, precision=200)
1.64493406684823
sage: pari.lfun(lf, ComplexField(200)(2))
1.64493406684823

I also have a difficulty with passing a function as you suggested.

comment:24 in reply to:  23 Changed 4 years ago by Jeroen Demeyer

Replying to chapoton:

Concerning precision, this is not so easy..

Don't confuse the printed output by PARI with the actual output. Try again adding .sage() to those examples.

comment:25 Changed 4 years ago by git

Commit: 8efdaf7702c14ed1761ceb42f11c6700f35aba86ccc3d7f706935f5a02719a686c484a8f517ca3d6

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

ccc3d7fsome details in #26098

comment:26 in reply to:  23 Changed 4 years ago by Jeroen Demeyer

Replying to chapoton:

I also have a difficulty with passing a function as you suggested.

Are you getting the error incorrect type in vecan_closure [wrong arity] (t_CLOSURE)? That could be considered a cypari2 bug.

comment:27 Changed 4 years ago by Jeroen Demeyer

Support for functions in cypari2 is still incomplete, but this hack works for me:

sage: def zeta_coeffs(n):
....:     return [1 for i in range(n)]
sage: zeta = pari.lfuncreate([pari("f -> (n -> f(n))")(zeta_coeffs), 1, [0], 1, 1, 1, 1])

It's quite important to keep a reference to the function zeta_coeffs, otherwise this will crash.

comment:28 Changed 4 years ago by git

Commit: ccc3d7f706935f5a02719a686c484a8f517ca3d6d153705675da7568191586aec32cab96f4a97758

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

d153705details

comment:29 Changed 4 years ago by git

Commit: d153705675da7568191586aec32cab96f4a97758641b84e57dcfa5b422ffaf3884efb49d4c870729

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

641b84etrac 26098 adding the Hardy function

comment:30 Changed 4 years ago by Frédéric Chapoton

some things that remain to be done:

  • be able to have L function for Dirichlet characters
  • fix the doctest with Ramanujan tau, how to handle that ?
  • make sure that poles and residues are handled correctly
Last edited 4 years ago by Frédéric Chapoton (previous) (diff)

comment:31 Changed 4 years ago by Frédéric Chapoton

Description: modified (diff)

comment:32 Changed 4 years ago by git

Commit: 641b84e57dcfa5b422ffaf3884efb49d4c87072933170b3929a218de25d705976c8c204fced2a860

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

33170b3toward dirichlet chars

comment:33 Changed 4 years ago by Frédéric Chapoton

Description: modified (diff)

comment:34 Changed 4 years ago by git

Commit: 33170b3929a218de25d705976c8c204fced2a8607a878dda2638c21392e7cf8b275721eaedb45c66

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

7a878ddtrac 26098 work on Dirichlet characters

comment:35 Changed 4 years ago by Frédéric Chapoton

Dependencies: #25567

according to K. Belabas, one should rather wait for pari 2.11

comment:36 Changed 4 years ago by git

Commit: 7a878dda2638c21392e7cf8b275721eaedb45c66cf501609842feb5235976b05930bc89e7f9702ac

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

cf50160trac 26098 interface for the L-functions setting of Pari

comment:37 Changed 4 years ago by git

Commit: cf501609842feb5235976b05930bc89e7f9702ac98a04a175f3254cac6ce0aff2e8062a6ded9394f

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

eb445f7Merge branch 'u/chapoton/26098' in 8.4.b2
98a04a1work on Pari L-function of Dirichlet chararacters

comment:38 Changed 4 years ago by git

Commit: 98a04a175f3254cac6ce0aff2e8062a6ded9394fe4053ea3b18a81bb74b3cbb424070f97fad8a007

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

e4053eaadding lfunction method to Dirichlet characters

comment:39 Changed 4 years ago by git

Commit: e4053ea3b18a81bb74b3cbb424070f97fad8a007bc30647c0697e6345c22d8e5652508aa0944d031

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

bcb62a5Merge branch 'u/chapoton/26098' in 8.4.b3
bc30647work on pari L-functions

comment:40 Changed 4 years ago by Jeroen Demeyer

Dependencies: #25567

comment:41 Changed 4 years ago by Frédéric Chapoton

Still not able to make that work:

+        sage: from sage.lfunctions.lfunctions_pari import lfun_generic, LFunction
+        sage: lf = lfun_generic(conductor=1, gammaV=[0,1], weight=12, eps=1)
+        sage: tau = pari('n->(5*sigma(n,3)+7*sigma(n,5))*n/12 - 35*sum(k=1,n-1,(6*k-4*(n-k))*sigma(k,3)*sigma(n-k,5))')
+        sage: lf.init_coeffs(tau)
+        sage: L = LFunction(lf)

comment:42 Changed 4 years ago by Jeroen Demeyer

To make it easier for me to help, it would be good to say why it doesn't work. I don't want to recompile this branch this branch every time just to answer your comments.

comment:43 Changed 4 years ago by Frédéric Chapoton

Well.

sage: from sage.lfunctions.lfunctions_pari import lfun_generic, LFunction
sage: lf = lfun_generic(conductor=1, gammaV=[0,1], weight=12, eps=1)
sage: tau = pari('n->(5*sigma(n,3)+7*sigma(n,5))*n/12 - 35*sum(k=1,n-1,(6*k-4*(n
....: -k))*sigma(k,3)*sigma(n-k,5))')
sage: lf.init_coeffs(tau)
sage: L = LFunction(lf)

All this works, or seems to. But here is the traceback.

sage: L(5)
---------------------------------------------------------------------------
PariError                                 Traceback (most recent call last)
<ipython-input-6-fd3c681015b7> in <module>()
----> 1 L(Integer(5))

/home/chapoton/sage/local/lib/python2.7/site-packages/sage/lfunctions/lfunctions_pari.pyc in __call__(self, s)
    635             pass
    636         try:
--> 637             value = pari.lfun(self._L, s, precision=self.prec).sage()
    638         except NameError:
    639             raise ArithmeticError('pole here')

cypari2/auto_instance.pxi in cypari2.pari_instance.Pari_auto.lfun()

cypari2/handle_error.pyx in cypari2.handle_error._pari_err_handle()

PariError: incorrect type in vecan_closure (t_INT)

Not clear to me where this "t_INT" could come from. And the failure appears only at a late stage..

comment:44 Changed 4 years ago by Jeroen Demeyer

The function is supposed to return a vector with n components, not a single number. See the docs for lfuncreate.

So you should conceptually replace n->f(n) by n->vector(n, k, f(k)).

comment:45 Changed 4 years ago by git

Commit: bc30647c0697e6345c22d8e5652508aa0944d031833f3ba6e86e83fb64b39ed53864e3e2d7116321

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

833f3bapari L-functions, fix syntax for call with functions

comment:46 Changed 4 years ago by git

Commit: 833f3ba6e86e83fb64b39ed53864e3e2d7116321b9bf637b0feb9b3cb3a2e27d9b33e58e73d5dd5c

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

b9bf637trac 26098 interface for the L-functions setting of Pari

comment:47 Changed 4 years ago by git

Commit: b9bf637b0feb9b3cb3a2e27d9b33e58e73d5dd5c01a330dc3fdb1ae74993ee1f89f9a804156232ac

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

01a330dadding the case of L-function for the Delta modular form

comment:48 Changed 4 years ago by git

Commit: 01a330dc3fdb1ae74993ee1f89f9a804156232acd105016b51e59b44e9e265aa8372b4541e79a3b4

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

d105016adding other types of L-functions

comment:49 Changed 4 years ago by git

Commit: d105016b51e59b44e9e265aa8372b4541e79a3b4c3c60b1af85a4574c2a162f46b0bf33625357658

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

c3c60b1L-function for elliptic curves over number fields

comment:50 Changed 4 years ago by git

Commit: c3c60b1af85a4574c2a162f46b0bf336253576581e3b387b54069bbc9ac72c2b4ae1e1bd03f7ecb8

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

1e3b387trac 26098 coverage 100%

comment:51 Changed 4 years ago by Frédéric Chapoton

ok, bot is green. Maybe ready for a first review ?

comment:52 Changed 4 years ago by John Cremona

Just a few quick comments to start with, as I have not yet built the code or looked in detail at the new interface:

  1. In the example for a Dirichlet L-function can you add the display of L itself to show the effect of its having been renamed?
  1. The docstring for delta_lseries is surely wrong: only one of the options interfaces with the (soon to be obsolete?) code of Tim Dok. And why is the default not the new pari version? Same for Dedekind Zeta.
  1. Should we have some examples computed with both gp and pari to show how they compare?

comment:53 Changed 4 years ago by git

Commit: 1e3b387b54069bbc9ac72c2b4ae1e1bd03f7ecb83f667241a3d4641332f3a5e1ca61ce5bd6475422

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

3f66724trac 2609_ fix doc of delta_lseries

comment:54 Changed 4 years ago by git

Commit: 3f667241a3d4641332f3a5e1ca61ce5bd6475422c1fa53345f2889986eba0f27f3b8878aefa5cb0f

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

c1fa533trac 26098 fix

comment:55 in reply to:  52 Changed 4 years ago by Frédéric Chapoton

Replying to cremona:

Just a few quick comments to start with, as I have not yet built the code or looked in detail at the new interface:

  1. In the example for a Dirichlet L-function can you add the display of L itself to show the effect of its having been renamed?

Sure, done.

  1. The docstring for delta_lseries is surely wrong: only one of the options interfaces with the (soon to be obsolete?) code of Tim Dok. And why is the default not the new pari version? Same for Dedekind Zeta.

Fixed the docstring of delta_lseries

Concerning the switch to "pari" by default, maybe this new interface is not yet mature enough.

  1. Should we have some examples computed with both gp and pari to show how they compare?

But this is already the case, I think.

comment:56 Changed 4 years ago by git

Commit: c1fa53345f2889986eba0f27f3b8878aefa5cb0fea66f8987db654568b9002dd33c0180d7c07278a

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

ea66f89trac 26098 fix details

comment:57 Changed 4 years ago by git

Commit: ea66f8987db654568b9002dd33c0180d7c07278ac1311d5f9c372bbe00eb3b36f072c228dc01f3d0

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

c1311d5trac 26098 interface for the L-functions setting of Pari

comment:58 Changed 4 years ago by git

Commit: c1311d5f9c372bbe00eb3b36f072c228dc01f3d09dec5842840c084dab33da617b8fb23e0569e2b4

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

9dec584trac 26098 work on Dirichlet characters

comment:59 Changed 4 years ago by git

Commit: 9dec5842840c084dab33da617b8fb23e0569e2b4c1cf2678e2de2e56297ab0a281b515a61284bd23

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

c1cf267trac 26098 cut long doctest into short lines

comment:60 Changed 4 years ago by Jeroen Demeyer

As I mentioned before, try to avoid using the .sage() method for PARI objects, as it doesn't give control over the resulting parent. In general, an explicit conversion like

R(pari_object)

should be preferred over

pari_object.sage()
Last edited 4 years ago by Jeroen Demeyer (previous) (diff)

comment:61 Changed 4 years ago by Jeroen Demeyer

In other words: the .sage() method exists mostly for convenience, not for correctness.

comment:62 Changed 4 years ago by Jeroen Demeyer

The changes to src/sage/schemes/elliptic_curves/ell_generic.py look independent from the rest of this ticket, could they be split off?

comment:63 Changed 4 years ago by Frédéric Chapoton

Dependencies: #26232

I have separated the change in pari conversion of elliptic curves over number fields (#26232).

comment:64 Changed 4 years ago by git

Commit: c1cf2678e2de2e56297ab0a281b515a61284bd23afdc0d8bb26c17f85992b1b3c1038fdee81e1f7c

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

413ecd0trac 26098 interface for the L-functions setting of Pari
afdc0d8trac 26098 trying not to use .sage()

comment:65 Changed 4 years ago by Frédéric Chapoton

Not using ".sage()" seems to result in 3 or 4 less digits...

comment:66 Changed 4 years ago by John Cremona

I agree with @jdemeyer that using x.sage() is dangerous. I am right now writing code which gets some quite complicated data back from gp functions and am having to write customised conversion functions.

comment:67 Changed 4 years ago by git

Commit: afdc0d8bb26c17f85992b1b3c1038fdee81e1f7cf9211d99517193afec4632bc9b26f66ff6c1c43d

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

2193a19trac 26098 interface for the L-functions setting of Pari
7777b84trac 26098 trying not to use .sage()
f9211d9trac 26098 fixing doctests

comment:68 Changed 4 years ago by Frédéric Chapoton

Description: modified (diff)

comment:69 Changed 4 years ago by Frédéric Chapoton

the remaining failing doctest is due to the dependency to #26232

comment:70 Changed 4 years ago by git

Commit: f9211d99517193afec4632bc9b26f66ff6c1c43d0649b7799691023042ba0d5017328ab60ffc276d

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

0649b77trac 26098 interface for the L-functions setting of Pari

comment:71 Changed 4 years ago by Frédéric Chapoton

Replacing the last .sage() seems to result in 3 less digits in the results. Should I do that nevertheless ?

Failed example:
    L(2)
Expected:
    1.64493406684822644
Got:
    1.64493406684823

comment:72 Changed 4 years ago by John Cremona

Do you mean that it shows fewer decimals with .sage() than without? When converting to/from pari remember that Sage allows any bit precision but pari only allows multiples of 32 (or something like that). So often the underlying pari computation is more precise than necessary.

comment:73 Changed 4 years ago by git

Commit: 0649b7799691023042ba0d5017328ab60ffc276df170198af4143561fe36d950cc3b7fdf46d8561f

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

f170198trac 26098 interface for the L-functions setting of Pari

comment:74 Changed 4 years ago by Frédéric Chapoton

Any other comment on this proposal ? I feel that this is not quite polished, but maybe already useful. I would appreciate feedback.

comment:75 Changed 4 years ago by Frédéric Chapoton

Cc: David Lowry-Duda added
Milestone: sage-8.4sage-8.7

comment:76 Changed 4 years ago by Frédéric Chapoton

Dependencies: #26232

comment:77 Changed 4 years ago by Frédéric Chapoton

Authors: Frédéric Chapoton
Status: newneeds_review

comment:78 Changed 4 years ago by Jeroen Demeyer

Branch: u/chapoton/26098u/jdemeyer/26098

comment:79 Changed 4 years ago by Jeroen Demeyer

Commit: f170198af4143561fe36d950cc3b7fdf46d8561fc5858fa661ca4fcb96a7f423bbe753beb9995fa4

Rebased to 8.7.beta5 (fixed trivial merge conflict).


New commits:

c5858fatrac 26098 interface for the L-functions setting of Pari

comment:80 Changed 4 years ago by Jeroen Demeyer

I have various comments, but it's probably easier for both of us if I just add an extra commit.

comment:81 Changed 4 years ago by Frédéric Chapoton

Yes, for sure. Please do.

comment:82 Changed 4 years ago by git

Commit: c5858fa661ca4fcb96a7f423bbe753beb9995fa4b53fe6ed13a1a697cf3a7de78e8b3259dbbfe463

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

63750cbUse 'pari' algorithm by default for L-functions
266c613Rename lfunctions_pari -> pari
b53fe6eFurther fixes to PARI L-functions

comment:83 Changed 4 years ago by Jeroen Demeyer

This is very much work in progress. I'm currently working on cypari2 to add support for __floordiv__ (for some reason, this was missing) and closures of a given arity. That will help for this ticket.

comment:84 Changed 4 years ago by Jeroen Demeyer

Status: needs_reviewneeds_work

comment:85 Changed 4 years ago by Frédéric Chapoton

Keywords: lseries zeta added

comment:86 Changed 4 years ago by Frédéric Chapoton

@jdemeyer, is the cypari part now ok ? I have seen the floordiv was added.

comment:87 Changed 4 years ago by Jeroen Demeyer

Yes indeed, I added some functionality to cypari2.

comment:88 Changed 4 years ago by Frédéric Chapoton

Branch: u/jdemeyer/26098u/chapoton/26098
Commit: b53fe6ed13a1a697cf3a7de78e8b3259dbbfe463c902517d7ca39c0c586a2466c67eb412dc0a6d19

I have fixed some of the doctests. But I am slightly worried by the increase in the number of required coefficients.


New commits:

778dcebMerge branch 'u/jdemeyer/26098' in 8.7.b7
c902517trac 26098 fixing some of the doctests

comment:89 Changed 4 years ago by Jeroen Demeyer

One thing to note is that the default precision with the PARI implementation is 53, but it was 64 with the GP scripts.

comment:90 Changed 4 years ago by Erik Bray

Milestone: sage-8.7sage-8.8

Ticket retargeted after milestone closed (if you don't believe this ticket is appropriate for the Sage 8.8 release please retarget manually)

comment:91 Changed 3 years ago by git

Commit: c902517d7ca39c0c586a2466c67eb412dc0a6d19e179f7cbed931932ebae23dd29468d29a3538a06

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

11b04ebtrac 26098 interface for the L-functions setting of Pari
c8690e8Use 'pari' algorithm by default for L-functions
47bd670Rename lfunctions_pari -> pari
7215b8aFurther fixes to PARI L-functions
e2eeb03trac 26098 fixing some of the doctests
e179f7ctrac #26098 fix doctests

comment:92 Changed 3 years ago by Frédéric Chapoton

Status: needs_workneeds_review

doctests fixed, back to needs review

comment:93 Changed 3 years ago by Frédéric Chapoton

and the bot is now green

comment:94 Changed 3 years ago by Travis Scrimshaw

A comment and a question:

RANK 1 ELLIPTIC CURVE: -> .. RUBRIC:: Rank 1 elliptic curve (see, e.g., combinat/root_system/cartan_type.py)

Should init_coeffs be exposed to the user as a public function? If so, should it be allowed to be run multiple times?

comment:95 Changed 3 years ago by git

Commit: e179f7cbed931932ebae23dd29468d29a3538a060ecf8c1b43e9986bfa6f7ef52dba1b78d917b1ce

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

5e85c6cMerge branch 'u/chapoton/26098' in 8.8.b3
0ecf8c1using rubric as suggested

comment:96 Changed 3 years ago by Frédéric Chapoton

Can we please try to move on here ? This seems to me to be a progress over the current situation, even if a tiny one.

I think one can keep init_coeffs as a public method, to be used as explained:

+        Initialisation of a :pari:`lfun` from motivic data.
+
+        This can happen either in one stage or in two stages: the coefficients
+        can be given using the ``init`` keyword, or entered using
+        the :meth:`init_coeffs`.

There remains something not very clear about the handling of poles and residues.

I would like to get more feedback from lmfdb or pari people.

comment:97 Changed 3 years ago by git

Commit: 0ecf8c1b43e9986bfa6f7ef52dba1b78d917b1ce9d69f415b4826df03a2db35ba254f69e692d5765

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

a7f23b9trac 26098 interface for the L-functions setting of Pari
f29ca95Use 'pari' algorithm by default for L-functions
1e575b3Rename lfunctions_pari -> pari
4658c47Further fixes to PARI L-functions
3ae97a5trac 26098 fixing some of the doctests
03ea8bdtrac #26098 fix doctests
e1ed425using rubric as suggested
9d69f4132 bit fixes

comment:98 Changed 3 years ago by Erik Bray

Milestone: sage-8.8sage-8.9

Moving tickets from the Sage 8.8 milestone that have been actively worked on in the last six months to the next release milestone (optimistically).

comment:99 Changed 3 years ago by Frédéric Chapoton

bot is morally green

comment:100 Changed 3 years ago by Travis Scrimshaw

Sorry for taking time to get back to this.

I do not quite understand the necessity of the init_coeffs method. I feel like there would be more standard ways to refactor that out (for example, just allowing initialization as normal). Or is this meant to be something done more lazily? You could also remove the __init attribute by just setting self._L = None in the __init__ and checking against that.

A little bit better doc formatting IMO:

-    Create a PARI `L`-function (:pari:`lfun` instance) with
+    Create a PARI `L`-function (:pari:`lfun` instance) with::
 
-    ``lfun_generic(conductor, gammaV, weight, eps, poles, residues, init)``
+        lfun_generic(conductor, gammaV, weight, eps, poles, residues, init)

This seems dubious to me:

    values_on_gens = (chi(x) for x in pari_gens)

    # now compute the input for pari (list of exponents)
    P = chi.parent()
    if is_ComplexField(P.base_ring()):
        zeta = P.zeta()
        zeta_argument = zeta.argument()
        v = [int(round(x.argument() / zeta_argument))
             for x in values_on_gens()]   # <<<---- This part here
    else:
        dlog = P._zeta_dlog
        v = [dlog[x] for x in values_on_gens]

with value_on_gens being a generator object, I don't think it should be callable.

check_functional_equation could use some more standard docstring formatting.

Otherwise everything else LGTM. A lot of these points I do not care about too much (since I doubt I will ever use this code because it is outside my research area), but I still feel it is worth a quick moment of thought.

comment:101 Changed 3 years ago by git

Commit: 9d69f415b4826df03a2db35ba254f69e692d5765091f71b6100ec912d2e28c451ff87231abeee1e9

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

b3a8793trac 26098 interface for the L-functions setting of Pari
ed1b8bdUse 'pari' algorithm by default for L-functions
60cbdd4Rename lfunctions_pari -> pari
f1adcb1Further fixes to PARI L-functions
852104etrac 26098 fixing some of the doctests
fa4b096trac #26098 fix doctests
a3c1834using rubric as suggested
5aa972332 bit fixes
091f71bsome reviewer's suggestions

comment:102 Changed 3 years ago by Travis Scrimshaw

Reviewers: Travis Scrimshaw
Status: needs_reviewpositive_review

Thanks. LGTM. (Sorry, I didn't notice the update.)

comment:103 Changed 3 years ago by Karl-Dieter Crisman

Regarding the Dirichlet L-functions, see also #16477. Does this ticket supersede it or at least implement some of it? (Maybe it only does it for Dirichlet characters and not general arithmetic functions.)

comment:104 Changed 3 years ago by Volker Braun

Branch: u/chapoton/26098091f71b6100ec912d2e28c451ff87231abeee1e9
Resolution: fixed
Status: positive_reviewclosed
Note: See TracTickets for help on using tickets.