Opened 5 years ago

Last modified 4 weeks ago

#16477 needs_info enhancement

implement Dirichlet series

Reported by: rws Owned by:
Priority: major Milestone: sage-8.2
Component: number theory Keywords: moebius, zeta, sigma, euler_phi, euler, Dirichlet series
Cc: kcrisman, mkamalakshya, jonhanke, slelievre Merged in:
Authors: Jonathan Hanke, Ralf Stephan Reviewers: Kamalakshya Mahatab, Vincent Delecroix, Jeroen Demeyer, Jonas Jermann, Ralf Stephan
Report Upstream: N/A Work issues:
Branch: public/ticket/16477 (Commits) Commit: 9da86c7c3f81b216defe8d9f9a3c3ba665f8349b
Dependencies: Stopgaps:

Description (last modified by kcrisman)

kcrisman in comment:20:ticket:8383:

Did somebody say defining Dirichlet series? Here is an implementation that I haven't had time to try out but which might be a good basis for that. This sage-support thread may also be relevant, though I don't know how advanced that psage code is.

The following file lists some product forms and their corresponding generating functions, it should be used to pick doctests for the g.f. input part of this ticket. The resp. OEIS entries are partly conjectural. https://drive.google.com/file/d/0B4PmRyK1JXgHY29aa00zZnhib1k/

Followup: #18102

Attachments (1)

Dirichlet_series.sage (16.8 KB) - added by kcrisman 5 years ago.

Download all attachments as: .zip

Change History (79)

comment:1 Changed 5 years ago by kcrisman

  • Cc kcrisman added

comment:2 Changed 5 years ago by kcrisman

  • Description modified (diff)

Changed 5 years ago by kcrisman

comment:3 Changed 5 years ago by kcrisman

I've attached the relevant file as well.

comment:4 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:5 Changed 5 years ago by mkamalakshya

  • Cc mkamalakshya added

comment:6 Changed 5 years ago by mkamalakshya

  • Branch set to u/mkamalakshya/16477
  • Commit set to c0037b25193d56e87d03eabd9db705f60ef7d3d9

New commits:

c0037b2Made the patch in to branch.

comment:7 Changed 5 years ago by rws

  • Milestone changed from sage-6.4 to sage-wishlist

comment:8 Changed 5 years ago by kcrisman

See also how to do it in Pari. Indeed, it has multiplication of Dirichlet series and so forth. Maybe that could be used somehow, since it already exists and is presumably well-tested.

Last edited 5 years ago by kcrisman (previous) (diff)

comment:9 Changed 4 years ago by rws

This is not correct. The commit author (contrary to the committer) should show as Jonathan Hanke. This is done by using the --author option of git ci. I will change that.

comment:10 Changed 4 years ago by rws

  • Branch changed from u/mkamalakshya/16477 to public/dirichlet-series

comment:11 Changed 4 years ago by rws

  • Authors set to Jonathan Hanke
  • Cc jonhanke added
  • Commit changed from c0037b25193d56e87d03eabd9db705f60ef7d3d9 to cfcd3aa3626df3f54cbbfa37b21083dcb4976758
  • Status changed from new to needs_review

I also moved the file under modular/.


New commits:

cfcd3aa16477: original draft of Dirichlet series

comment:12 Changed 4 years ago by rws

  • Status changed from needs_review to needs_work

comment:13 Changed 4 years ago by git

  • Commit changed from cfcd3aa3626df3f54cbbfa37b21083dcb4976758 to d1f4d30faa64ca38c2fbdd9c728e39bffc60d01a

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

d1f4d3016477: adapt to Sage; fix most doctest failures

comment:14 Changed 4 years ago by rws

  • Authors changed from Jonathan Hanke to Jonathan Hanke, Ralf Stephan
  • Dependencies set to #18038
  • Work issues set to use pari, g.f. input

comment:15 Changed 4 years ago by jdemeyer

  • Dependencies changed from #18038 to #18038, #18041

comment:16 Changed 4 years ago by jdemeyer

About PARI: dirmul and dirdiv already work in Sage. direuler is difficult because of the syntax direuler(p=a,b,expr) involving a loop variable and an expression to be evaluated.

comment:17 Changed 4 years ago by git

  • Commit changed from d1f4d30faa64ca38c2fbdd9c728e39bffc60d01a to 949082ca407de7df7ae2ce31ecfad4f5d21f3ffa

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

386023516477: cleanup; switch from string to generating function input (limited impl.)
f67792316477: add dirmul, dirdiv to pari class gen
949082c16477: use dirmul, dirdiv; many fixes

comment:18 Changed 4 years ago by rws

  • Description modified (diff)

comment:19 Changed 4 years ago by jj

Hi

Just an idea:

Shouldn't it be possible to define/implement Dirichlet series by specifying a function (from Z/ideals/whatever) for their coefficients?

I guess that would require some base class (which ideally would accept/parse/recognize functions from Z/whatever) for the coefficient functions. It would do parsing tasks, printing(!) of functions, arithmetic operations/dirichlet convolutions/etc... (Completely) multiplicative functions would be a "nice" subclass. Ideally the implementation would at least support basic Dirichlet series example.

Again: Just an idea (for either an extension or a new implementation/ticket).

Regards, Jonas

Last edited 4 years ago by jj (previous) (diff)

comment:20 follow-up: Changed 4 years ago by kcrisman

You are quite right - so, does Pari support this? If not, then it's probably a fairly big job and should be a different ticket (while you should make sure that this ticket remains agnostic with respect to your questions so the backend can be changed). If yes, hopefully we could just hook into their stuff for anything nontrivial.

comment:21 Changed 4 years ago by rws

At the moment this is implemented:

sage: Lminus4 = dirichlet_series([kronecker(-4,n) for n in range(1,21)]); Lminus4
1 + -1/(3^s) + 1/(5^s) + -1/(7^s) + 1/(9^s) + -1/(11^s) + 1/(13^s) + -1/(15^s) + 1/(17^s) + -1/(19^s) + O(21^(-s))
sage: zeta = dirichlet_series([1]*20); zeta
1 + 1/(2^s) + 1/(3^s) + 1/(4^s) + 1/(5^s) + 1/(6^s) + 1/(7^s) + 1/(8^s) + 1/(9^s) + 1/(10^s) + 1/(11^s) + 1/(12^s) + 1/(13^s) + 1/(14^s) + 1/(15^s) + 1/(16^s) + 1/(17^s) + 1/(18^s) + 1/(19^s) + 1/(20^s) + O(21^(-s))
sage: zeta * Lminus4^(-1)
1 + 1/(2^s) + 2/(3^s) + 1/(4^s) + 2/(6^s) + 2/(7^s) + 1/(8^s) + 2/(9^s) + 2/(11^s) + 2/(12^s) + 2/(14^s) + 1/(16^s) + 2/(18^s) + 2/(19^s) + O(21^(-s))

Please give a concrete example what you like to see!

comment:22 Changed 4 years ago by rws

I just found this: https://github.com/williamstein/psage/blob/master/psage/lseries/eulerprod.py#L1128

EDIT: This has much more generality and lets this ticket look like a child's toy, so there 8P

Last edited 4 years ago by rws (previous) (diff)

comment:23 in reply to: ↑ 20 Changed 4 years ago by jdemeyer

Concerning the dependencies #18038 and #18041: if you want to use direuler now, you can still do it using strings: pari("direuler(...)") should work just like in GP:

sage: pari("direuler(p=2, 20, 1/(1-X)/(1-p*X))")
[1, 3, 4, 7, 6, 12, 8, 15, 13, 18, 12, 28, 14, 24, 24, 31, 18, 39, 20, 42]

comment:24 follow-up: Changed 4 years ago by jj

rws:

I'm in particular hoping for an exact implementation of arithmetic/multiplicative functions:

id = ArithmeticFunctions().id()
sigma0 = ArithmeticFunction(lambda n: sigma0(n))
id*id == sigma0 // Dirichlet convolution

...

f = DirichletSeries(id)*DirichletSeries(id)
f == DirichletSeries(sigma0)
f[91234154]
f // nice representations:
=> sum_{n in Z} (sum_{d|n} 1)
or: sum_{n in Z} sigma0(n)

...

Those certainly form a nice subset of possible coefficient functions / dirichlet series. More generally I was hoping for the possibility to specify Dirichlet series / coefficient functions exactly, not only up to some precision. E.g. (bad example) DirichletSeries?(lambda n: sin(n)) or e.g. by specifying an (exact) generating series as e.g. a rational function

Calculating the n'th coefficient from these to get a DirichletSeries? as now is at least rather simple.

Other ideas: exact verification of identities (not only up to precision), nice representations/output of coefficient functions after operations (hard), support functions from ideals (TODO: figure out the correct category for the domain of coefficient functions).

I am aware that this is not a small task and might not be easily possible in python. But I hope you get the idea of what I had in mind...

comment:25 Changed 4 years ago by kcrisman

That is probably a bit beyond this ticket, though maybe not. It would be nice to have such "symbolic" ones too.

comment:26 in reply to: ↑ 24 ; follow-up: Changed 4 years ago by rws

Replying to jj:

f = DirichletSeries(id)*DirichletSeries(id)
f == DirichletSeries(sigma0)
f[91234154]
f // nice representations:
=> sum_{n in Z} (sum_{d|n} 1)
or: sum_{n in Z} sigma0(n)

nice representations/output of coefficient functions after operations (hard),

That would first need conversion of the g.f. into divisor sum form. Another ticket.

id = ArithmeticFunctions().id()
sigma0 = ArithmeticFunction(lambda n: sigma0(n))
id*id == sigma0 // Dirichlet convolution

That would need ability to compute a g.f. from the coefficients. I think this is possible but hard.

support functions from ideals (TODO: figure out the correct category for the domain of coefficient functions).

And a third ticket.

So this ticket would prepare for the others by providing creation from expressions of a limited form (polynomial fractions with generator from zeta(a*s+b) and L(c)).

comment:27 in reply to: ↑ 26 ; follow-up: Changed 4 years ago by jj

Replying to rws:

Replying to jj:

f = DirichletSeries(id)*DirichletSeries(id)
f == DirichletSeries(sigma0)
f[91234154]
f // nice representations:
=> sum_{n in Z} (sum_{d|n} 1)
or: sum_{n in Z} sigma0(n)

nice representations/output of coefficient functions after operations (hard),

That would first need conversion of the g.f. into divisor sum form. Another ticket.

There are (at least) two different (exact) approaches:

  • Coefficient functions
  • Generating functions (as q-series?), I am not entirely sure what you mean by it...

I was emphasizing on the coefficient function part. Clearly it is possible to define dirichlet series by specifying the coefficient function (as a normal function). It is even relatively simple to implement all kind of operations. Individual coefficients could also be calculated (up to some precision). What is hard is getting a "nice representation" (e.g. a divisor sum form as you mentioned above).

  • One idea might be to somehow "decompile" a function into source code / some at least nicer form.
  • One idea might be to use symbolic expression (rather limited).
  • Another idea might be to implement very basic coefficient functions and allow all kind of operations with them (using ast(?)/whatever) to be as flexible as possible with the combinations (include as many of the popular examples as possible).
  • Finally we could simply use the old representation by just calculating the coefficients up to some precision. The advantage would be that "precision" is no longer part of the series, only of the representation.
id = ArithmeticFunctions().id()
sigma0 = ArithmeticFunction(lambda n: sigma0(n))
id*id == sigma0 // Dirichlet convolution

That would need ability to compute a g.f. from the coefficients. I think this is possible but hard.

The relation between coefficient functions and generating series might be a challenge. I wonder what approach is more suitable. Maybe the two concepts both have interesting cases that cannot easily be translated to the other way. So maybe both ways should be supported (?).

support functions from ideals (TODO: figure out the correct category for the domain of coefficient functions).

And a third ticket.

So this ticket would prepare for the others by providing creation from expressions of a limited form (polynomial fractions with generator from zeta(a*s+b) and L(c)).

I was thinking in very general terms ("any" function from Z). That should be fairly simple (even with operations on series) and allow the calculation of the coefficients up to an arbitrary precision. Example:

(F+G).cf = lambda n: F.cf(n) + G.cf(n)
(F*G).cf = lambda n: sum(F.cf(d)*G.cf(n/d) for d in divisors(n))

However it will be very hard to get "nice" representation of the coefficient functions.

Maybe "polynomial fractions with genertore from zeta(a*s+b) and L(c)" is more powerful, I don't know.

Side remark: *Dirichlet series* could/should be viewed as something like a *Fourier transform* of an *Arithmetic function*.

Last edited 4 years ago by jj (previous) (diff)

comment:28 in reply to: ↑ 27 ; follow-up: Changed 4 years ago by rws

Replying to jj:

  • Generating functions (as q-series?), I am not entirely sure what you mean by it...

See https://en.wikipedia.org/wiki/Generating_function#Dirichlet_series_generating_functions

comment:29 in reply to: ↑ 28 ; follow-up: Changed 4 years ago by jj

Replying to rws:

Replying to jj:

  • Generating functions (as q-series?), I am not entirely sure what you mean by it...

See https://en.wikipedia.org/wiki/Generating_function#Dirichlet_series_generating_functions

Yes but that doesn't explain how the g.f. is implemented (in an exact way). For some families of Dirichlet series the corresponding ordinary (or exponential) generating series could be stored as a rational function (e.g. 1/(1-q)).

I assumed you meant this when refering to g.f. How else could you store the g.f. in an exact matter?

comment:30 in reply to: ↑ 29 Changed 4 years ago by rws

Replying to jj:

How else could you store the g.f. in an exact matter?

Nearly all D.g.f.'s I have seen (and certainly all that generate your arithmetic functions) are polynomials in A. zeta(as+b), B. L(chi(c,d), s), C. (1-e^(-s+f)), with a,b,c,d,e,f integer. Okay, this is not a proof, but well supported by data in the OEIS. So I want to store that polynomial.

comment:31 follow-up: Changed 4 years ago by kcrisman

I agree that both of these representations are useful and desired. Would it be possible to implement the basics here - esp. since it turns out Pari has a lot of the functionality we need - and then put the generating function stuff (which I would also use) in a separate ticket? I'm just concerned that this will never happen despite a lot of enthusiasm.

comment:32 in reply to: ↑ 31 Changed 4 years ago by jj

Unfortunately experience shows that this concern is well founded. So yes, I agree.

comment:33 follow-up: Changed 4 years ago by jj

Just for your information:

I started some preliminary (poc) test implementation of arithmetic functions (no tests/documentation etc). The first idea was to use symbolic expressions but they don't work well together with sums which are absolutely crucial for operations on arithmetic functions...

The test implementation is available on u/jj/arith_functions:

http://git.sagemath.org/sage.git/commit/?id=526e1ae40f94cff95e5dc6926208b831643edfb4

Here is a simple example:

sigma3 = ArithmeticFunction(lambda n: sigma(n,3), lambda n,_: "sigma({},3)".format(n), lambda n,_: "\\sigma_{{3}}\\left({}\\right)".format(n))
sigma3^2
show(sigma3^2)
(sigma3^2)(5)

comment:34 in reply to: ↑ 33 ; follow-up: Changed 4 years ago by rws

Replying to jj:

I started some preliminary (poc) test implementation of arithmetic functions (no tests/documentation etc).

http://git.sagemath.org/sage.git/commit/?id=526e1ae40f94cff95e5dc6926208b831643edfb4

I think you should open an enhancement ticket for this branch, just to make it possible to discuss specifics. Note: I am supporting your effort of formulating the algebraic side of these functions. Note too that Dirichlet series represent a superset of these functions, so your code cannot serve as the parent ring implementation of this ticket, and a different ticket is needed.

comment:35 in reply to: ↑ 34 Changed 4 years ago by jj

Ok, I created a ticket: http://trac.sagemath.org/ticket/18102

Regarding Dirichlet series: It seems that rational functions (over what?) might provide a nice (internal) basis for how (exact) Dirichlet series are stored. The coefficients can be calculated and it should be possible to automatically define a corresponding coefficient function. This would still benefit from a nice base class for arithmetic functions (in particular since we know to construct/represent the coefficient function, this additional information could be "passed on" to / used by the arithmetic function element).

comment:36 Changed 4 years ago by rws

  • Branch changed from public/dirichlet-series to u/rws/16477-1

comment:37 Changed 4 years ago by rws

  • Commit changed from 949082ca407de7df7ae2ce31ecfad4f5d21f3ffa to 5698ef17c2be57ebe3826737cdba43f12c6bb8d6
  • Dependencies #18038, #18041 deleted
  • Milestone changed from sage-wishlist to sage-6.6
  • Status changed from needs_work to needs_review

This version now supports generating functions of a certain form. Please see the documentation. This should suffice as a first version. Further development possibilities were already discussed in this ticket.

Please review.


New commits:

05c8cbaMerge branch 'develop' into tmp9
5698ef116477: adapt code to Sage; rewrite to allow generated series

comment:38 follow-up: Changed 4 years ago by vdelecroix

  • Status changed from needs_review to needs_work

Hello,

  1. there is no need to add method dirmul and dirdiv to the pari gen object. This is taken care automatically since #17631. Doctesting is cool thoug. But move it somewhere else.
  1. Why is this new module in sage.modular? It makes no sense.
  1. You should try harder to use pari and not gp. Since #17631, most functions are available directly in pari.
  1. DirichletSeries would better inherit from RingElement. In that case, you must not define __add__, __mul__, __div__ etc but _add_, _mul_, _div_. That way you will get benefits from coercion (e.g. multiplication by scalars). You might have a look to polynomials (in sage.rings.polynomials.* or power series (in sage.rings.power_series_*).
  1. What is the purpose of the commented code?
  1. The error must be new style ones. Please use
        raise MyError("my message")
    
    instead of
        raise MyError, "my message"
    

Vincent

comment:39 in reply to: ↑ 38 ; follow-up: Changed 4 years ago by rws

Replying to vdelecroix:

Thanks, I accept points 1 and 6 but:

  1. Why is this new module in sage.modular? It makes no sense.

The Dirichlet characters are there too. I don't see why not.

  1. You should try harder to use pari and not gp. Since #17631, most functions are available directly in pari.

But not those needing closures, see comment:16 and #18038

  1. DirichletSeries would better inherit from RingElement. In that case, you must not define __add__, __mul__, __div__ etc but _add_, _mul_, _div_. That way you will get benefits from coercion (e.g. multiplication by scalars). You might have a look to polynomials (in sage.rings.polynomials.* or power series (in sage.rings.power_series_*).

This is clearly a separate ticket.

  1. What is the purpose of the commented code?

I didn't want to erase useful ideas of the original author.

comment:40 in reply to: ↑ 39 ; follow-up: Changed 4 years ago by vdelecroix

Hello,

Replying to rws:

Replying to vdelecroix:

  1. Why is this new module in sage.modular? It makes no sense.

The Dirichlet characters are there too. I don't see why not.

Because sage.modular is intended for modular forms. A Dirichlet serie is not necessarily a modular form. To me, modules and submodules should work by inclusion. Or at least try to.

I do not see Dirichlet series as a subset of modular forms. I perfectly understand the reason why it is here, but it would be better in sage.functions or sage.rings. The directory sage.modular really contains too much stuff. This is historical as people that initiated Sage were very interested in modular forms.

  1. You should try harder to use pari and not gp. Since #17631, most functions are available directly in pari.

But not those needing closures, see comment:16 and #18038

I see! Do you mind adding a comment in the docstring saying that as soon as #18038 is ready, this can be modified?

  1. What is the purpose of the commented code?

I didn't want to erase useful ideas of the original author.

Why letting it commented then?

Vincent

comment:41 in reply to: ↑ 40 ; follow-up: Changed 4 years ago by vdelecroix

Replying to vdelecroix:

Hello,

Replying to rws:

Replying to vdelecroix:

  1. Why is this new module in sage.modular? It makes no sense.

The Dirichlet characters are there too. I don't see why not.

Because sage.modular is intended for modular forms. A Dirichlet serie is not necessarily a modular form. To me, modules and submodules should work by inclusion. Or at least try to.

I do not see Dirichlet series as a subset of modular forms. I perfectly understand the reason why it is here, but it would be better in sage.functions or sage.rings. The directory sage.modular really contains too much stuff. This is historical as people that initiated Sage were very interested in modular forms.

What do you think of sage.lfunctions?

Vincent

comment:42 in reply to: ↑ 41 ; follow-up: Changed 4 years ago by rws

Replying to vdelecroix:

What do you think of sage.lfunctions?

What else would you put in there (I have no idea myself)?

comment:43 in reply to: ↑ 42 Changed 4 years ago by vdelecroix

Replying to rws:

Replying to vdelecroix:

What do you think of sage.lfunctions?

What else would you put in there (I have no idea myself)?

You can first have a look to what is already in.

comment:44 Changed 4 years ago by rws

I vaguely remember having had a look at some time but now I see you're right.

comment:45 follow-up: Changed 4 years ago by jj

Replying to rws:

I vaguely remember having had a look at some time but now I see you're right.

Note that L-function / L-series usual refer to functions / series satisfying some very specific (more restrictive) set of axioms (AC/FE/etc) - in contrast to Dirichlet series or abstract Dirichlet series. So there is definitely some justification for introducing a new class (at least if it supports exact representation).

Also if I remember correctly the L-function is not an exact representation but also restricted by precision. What I would like to see is support for exact abstract Dirichlet series, e.g. by using symbolic coefficient functions or by using exact generating series in terms of rational functions.

If they are not implemented in an exact way I am curious about the background: How / in what context will they be used? Why is a new class required?

In any case I agree that Dirichlet series don't belong to sage.modular.

Best

Jonas

comment:46 in reply to: ↑ 45 Changed 4 years ago by vdelecroix

Hello Jonas,

Replying to jj:

Thanks for your input. After reading your comment I think that one reasonable option is to create a new module dirichlet_series and move lfunctions in there. What do you think?

Vincent

comment:47 follow-up: Changed 4 years ago by kcrisman

I'm not sure that would be as useful of a top-level module, and might break some existing code that imports them. I agree it would be confusing to have this in lfunctions, but not as confusing as having it somewhere else!

comment:48 in reply to: ↑ 47 Changed 4 years ago by vdelecroix

Replying to kcrisman:

I'm not sure that would be as useful of a top-level module, and might break some existing code that imports them. I agree it would be confusing to have this in lfunctions, but not as confusing as having it somewhere else!

It is not a problem to keep the old lfunctions module as an alias for dirichlet_series.lfunctions (if we really care, there can be a deprecated alias). But for matter of code organisation that would be better to have lfunctions included in dirichlet_series.

Vincent

comment:49 Changed 4 years ago by git

  • Commit changed from 5698ef17c2be57ebe3826737cdba43f12c6bb8d6 to c595740c4b6e92da37f2ed90579f4a3f5664923b

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

39fc588Merge branch 'develop' into t/16477/16477-1
2b1a89616477: move to lfunctions/; delete code in pari/gen
c59574016477: cosmetics

comment:50 Changed 4 years ago by rws

  • Status changed from needs_work to needs_review
  • Work issues use pari, g.f. input deleted

That addresses all discussed issues save the new module, which IMHO should be a separate ticket and discussed on sage-devel.

comment:51 Changed 4 years ago by vdelecroix

Hello,

Thanks for moving it! You need to add an entry to your new file to get it included in the documentation (this is one line in $SAGE_ROOT/doc/en/reference/lfunctions/index.rst).

Vincent

comment:52 follow-up: Changed 4 years ago by vdelecroix

  • Status changed from needs_review to needs_work
  • Work issues set to documentation, elementary operations

Hello,

6 more questions/issues.

  1. Why are you importing the alias dirichlet_series and not DirichletSeries in the global namespace?
  1. How do I get the coefficients of the Dirichlet L functions obtained with the command dirichlet_L(3,2,s)?
  1. There are several issues with the documentation:
    • you forgot :: at line 107 (in DirichletSeries class documentation).
    • the INPUT block does not follow the convention (see the developer guide, section Documentation String)
    • doctests are missing from many important functions (e.g. base_ring, is_Eulerian, has_infinite_precision, list)
  1. In __mul__ I do not understand
    R = self.base_ring() 
    try: 
        _ = RR(other)
    
    Did you want to write R(other)? If so it is very wrong since if you multiply 2.0 with a Dirichlet serie with rational coefficients you would end up with rational coefficients as
    sage: QQ(3.2314)
    16157/5000
    
    You should really use coercion here (i.e. the item 4 in comment:38) or do stronger type check such as parent(other) is self.base_ring().
  1. This should work
    sage: D1 = dirichlet_series([1,1,1])
    sage: D1 + 1
    Traceback (most recent call last):
    ...
    

(also related to item 4 in comment:38).

  1. What is the purpose of this nested MaskFunction class?

Vincent

comment:53 Changed 4 years ago by git

  • Commit changed from c595740c4b6e92da37f2ed90579f4a3f5664923b to 7f254972105d6555d1a1d209fe17e65beec557db

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

7f2549716477: improve +/*, documentation

comment:54 in reply to: ↑ 52 Changed 4 years ago by rws

Replying to vdelecroix:

  1. How do I get the coefficients of the Dirichlet L functions obtained with the command dirichlet_L(3,2,s)?

Analogous to polynomial coefficients, now added as example:

sage: D=dirichlet_series(dirichlet_L(3,2,s))
sage: D.list()
[1, -1, 0, 1, -1, 0, 1, -1, 0, 1, -1, 0, 1, -1, 0, 1, -1, 0, 1, -1]
sage: D.list(5)
[1, -1, 0, 1, -1]
  1. In __mul__ I do not understand
    R = self.base_ring() 
    try: 
        _ = RR(other)
    
    Did you want to write R(other)?

I haven't looked extensively at Jon's code as long as it worked.

You should really use coercion here (i.e. the item 4 in comment:38) or do stronger type check such as parent(other) is self.base_ring().

  1. This should work
    sage: D1 = dirichlet_series([1,1,1])
    sage: D1 + 1
    Traceback (most recent call last):
    ...
    

No, this is a feature request. With this ticket you can do as well:

sage: D1 = dirichlet_series([1,1,1])
sage: one = dirichlet_series(1)
sage: D1 + one                                                                          
2 + 1/(2^s) + 1/(3^s) + O(4^(-s))                                                       
  1. What is the purpose of this nested MaskFunction class?

As this is only of developer interest I added at l.156:

                # the specific form of the factors returned by Maxima
                # (see ticket #18081) makes masking necessary
                arg = dirichlet_series._mask_exp_factors(arg)

The rest should be addressed with the latest commit.

comment:55 Changed 4 years ago by rws

  • Status changed from needs_work to needs_review

comment:56 Changed 4 years ago by kcrisman

  • Reviewers set to Kamalakshya Mahatab, Vincent Delecroix, Jeroen Demeyer, Jonas Jermann

comment:57 Changed 4 years ago by kcrisman

  • Description modified (diff)

comment:58 Changed 4 years ago by git

  • Commit changed from 7f254972105d6555d1a1d209fe17e65beec557db to ae323c3bd7dfb925191dba9239b434fc02c930a1

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

73f7f92Merge branch 'develop' into t/16477/16477-1
ae323c316477: adapt to changes in add expressions

comment:59 Changed 3 years ago by git

  • Commit changed from ae323c3bd7dfb925191dba9239b434fc02c930a1 to 8c2640114ced6b5a6ad82ed0486303034f0ea78a

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

23d89f0Merge branch 'develop' into t/16477/16477-1
8c2640116477: fix import

comment:60 Changed 3 years ago by rws

  • Milestone changed from sage-6.6 to sage-7.3
  • Work issues documentation, elementary operations deleted

comment:61 Changed 3 years ago by kcrisman

What is the status of review on this? I.e., what does the latest reviewer/author (rws) believe still needs review? I personally dearly wish for convolution/DP but I think I won't get that on this ticket and better to have this in than not.

comment:62 Changed 3 years ago by slelievre

  • Cc slelievre added
  • Keywords Dirichlet series added

comment:63 Changed 2 years ago by rws

  • Branch changed from u/rws/16477-1 to u/rws/16477-2

comment:64 Changed 2 years ago by rws

  • Commit changed from 8c2640114ced6b5a6ad82ed0486303034f0ea78a to f3ce7ad3e95642f3474e595dcadbd31cdd3db5ff
  • Milestone changed from sage-7.3 to sage-8.0

Squashed, used lazy import, and completed coverage.


New commits:

f3ce7ad16477: implement Dirichlet series

comment:65 follow-up: Changed 2 years ago by kcrisman

Curious whether this supports e.g. a Dirichlet series from the Möbius function (I couldn't find an example like that, other than the evident one where you take the appropriate version of zeta - but that is a theorem, not a series).

It looks quite nice. Ralf, what piece of this would you say still needs review? After all, I think at least some of it you have in essence reviewed Jon Hanke's work. So it would be nice to know what would still need a good hard look.

Final note - I'm confused by the dummy. Is that something from pari or Sage?

comment:66 in reply to: ↑ 65 ; follow-up: Changed 2 years ago by rws

Replying to kcrisman:

Curious whether this supports e.g. a Dirichlet series from the Möbius function (I couldn't find an example like that, other than the evident one where you take the appropriate version of zeta - but that is a theorem, not a series).

I don't understand. The Dirichlet g.f. of the Moebius function is 1/zeta(s) via Sum_{n >= 1} mu(n)/n^s = 1/zeta(s) so you can get it via:

sage: var('s')
s
sage: dirichlet_series(1/zeta(s))
1 + -1/(2^s) + -1/(3^s) + -1/(5^s) + 1/(6^s) + -1/(7^s) + 1/(10^s) + -1/(11^s) + -1/(13^s) + 1/(14^s) + 1/(15^s) + -1/(17^s) + -1/(19^s) + O(20^(-s))
sage: _.list()
[1, -1, -1, 0, -1, 1, -1, 0, 0, 1, -1, 0, -1, 1, 1, 0, -1, 0, -1, 0]

It looks quite nice. Ralf, what piece of this would you say still needs review? After all, I think at least some of it you have in essence reviewed Jon Hanke's work. So it would be nice to know what would still need a good hard look.

The conversion from g.f. to the form Pari uses for generation is unpublished research. If I insist on a review it will never go into Sage so what do I say? I tested it on all known D.g.f.s collected from the OEIS. But there are surely future cases where it will fail.

Final note - I'm confused by the dummy. Is that something from pari or Sage?

It is only used internally for pattern matching. If there is a next version pattern matching will be done in Pynac.

comment:67 in reply to: ↑ 66 ; follow-up: Changed 2 years ago by kcrisman

  • Reviewers changed from Kamalakshya Mahatab, Vincent Delecroix, Jeroen Demeyer, Jonas Jermann to Kamalakshya Mahatab, Vincent Delecroix, Jeroen Demeyer, Jonas Jermann, Ralf Stephan

Replying to rws:

Replying to kcrisman:

Curious whether this supports e.g. a Dirichlet series from the Möbius function (I couldn't find an example like that, other than the evident one where you take the appropriate version of zeta - but that is a theorem, not a series).

I don't understand. The Dirichlet g.f. of the Moebius function is 1/zeta(s) via Sum_{n >= 1} mu(n)/n^s = 1/zeta(s) so you can get it via:

What I meant was precisely that I knew you could do that, but one might want to just plug Moebius in if (say) one didn't know this fact. (And not just for finitely many values.) But apparently not, which is fine for now.

The conversion from g.f. to the form Pari uses for generation is unpublished research. If I insist on a review it will never go into Sage so what do I say? I tested it on all known D.g.f.s collected from the OEIS. But there are surely future cases where it will fail.

Sure. I just meant that since this is currently "needs review", what things would still need to be looked at? You can presumably vouch for quite a bit not due to your self.

comment:68 in reply to: ↑ 67 ; follow-up: Changed 2 years ago by rws

Replying to kcrisman:

Sure. I just meant that since this is currently "needs review", what things would still need to be looked at? You can presumably vouch for quite a bit not due to your self.

I think it's ready but I can't set positive, can I?

comment:69 in reply to: ↑ 68 Changed 2 years ago by kcrisman

Sure. I just meant that since this is currently "needs review", what things would still need to be looked at? You can presumably vouch for quite a bit not due to your self.

I think it's ready but I can't set positive, can I?

Typically not, unless you really didn't add anything beyond window-dressing. Which is why I'm asking what you did add - I guess a lot of the examples, right? Any actual code? (Since you squashed I guess that won't be visible in the log.) Then anyone (hopefully me) who is ready can just review the pieces that are "new since you", if that makes sense.

comment:70 Changed 2 years ago by rws

Jon's code was completely rewritten, so you would have to review it all.

comment:71 Changed 2 years ago by kcrisman

Okay, that's a bigger job, but good for us to know. I didn't realize that. No, typically we don't review external Pari code, though, so no worries there.

comment:72 Changed 22 months ago by rws

  • Status changed from needs_review to needs_work

Import arith errors from patchbot.

Last edited 22 months ago by rws (previous) (diff)

comment:73 Changed 19 months ago by git

  • Commit changed from f3ce7ad3e95642f3474e595dcadbd31cdd3db5ff to f1a1adac9dab287cd9e68a480d8e37914a3afc84

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

dab32f7Merge branch 'develop' into t/16477/16477-2
f1a1adafix import

comment:74 Changed 19 months ago by rws

  • Milestone changed from sage-8.0 to sage-8.2
  • Status changed from needs_work to needs_review

comment:75 Changed 6 months ago by chapoton

  • Branch changed from u/rws/16477-2 to public/ticket/16477
  • Commit changed from f1a1adac9dab287cd9e68a480d8e37914a3afc84 to 9da86c7c3f81b216defe8d9f9a3c3ba665f8349b

New commits:

f2d0ffaMerge branch 'u/rws/16477-2' in 8.7.b6
9da86c7fix the pyflakes warnings

comment:76 follow-up: Changed 6 months ago by vdelecroix

  • Status changed from needs_review to needs_info

Why Dirichlet series derive from SageObject? Don't you want the Dirichlet series to form an algebra?

comment:77 in reply to: ↑ 76 Changed 5 months ago by kcrisman

Why Dirichlet series derive from SageObject? Don't you want the Dirichlet series to form an algebra?

Yes, since these are formal Dirichlet series, ideally they would be, see e.g. Shapiro Chapter 4.6.

comment:78 Changed 4 weeks ago by kcrisman

See also #26098 which possibly might overlap this (or even supersede it?).

Note: See TracTickets for help on using tickets.