Distribute symbolic sums over the terms of their first (sum) argument

[EmmanuelCharpentier]

Motivation : see this sage-support post and Ralf Stephan's answer.

A similar enhancement could distribute symbolic products over the factors of their first (product) argument, but symbolic products are currently broken (see #22914).

This ticket has been abandoned in favor of #22937.

CC: @rwst

Component: symbolics

Branch/Commit: u/charpent/expand_sum @ 19bd0be

Issue created by migration from https://trac.sagemath.org/ticket/22915

[EmmanuelCharpentier]

comment:1

This first implementation follows the guidelines suggested by Ralf Stephan. It is probably highly perfectible :

• The implementation is "pure Sage" : I am aware of the possibility of speeding it considerably by declaring types to the necessary functions and their arguments, but I'm unsure about the relevant types (I'm quite novice in Cython...).
• I am not sure that this distribution should occur in every expansion : one could add a keyword to the expand() method/function, with edault value being either True or False (to be discussed).
• Since the expand() method essentially dispatches the work to the components of the Expression, This specialized expansion could (should ?) take place as a method of Function_sum, but I'm currently unablke on how to do this (this is my first ever attempt to work on the Sage symbolics in the library).

Suggestions, criticisms, even lazzi are welcome as long as they are constructive...

I'm not marking this as needs_review, since the documentation remains to be written. I may push a documentation patch and mark it needs_review soon.

[EmmanuelCharpentier]

Branch: u/charpent/expand_sum

[sagetrac-git]

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

19bd0be

Documentation of the distribution of symbolic sums over sums.

[sagetrac-git]

Commit: 19bd0be

[EmmanuelCharpentier]

comment:3

Passes ptestlong with thye same problems as with 8.0.beta4 (see this post on sage-release).

==> needs_review. But again, this is functional, but largely perfectible.

[rwst]

comment:5

I would call this only if the expression contains sums, test it via e.g.:

sage: w=SR.wild()
sage: ex = sum(x+x^2,x,1,n,hold=True)
sage: ex.has(sum(w,x,1,m,hold=True))
False
sage: ex.has(sum(w,x,1,n,hold=True))
True

Minor cosmetics would be to give ES a more descriptive name. Also you need spaces after commata, semicola, and around equal signs for convention. Finally please test if your documentation builds, the doctest spacing looks wrong. Oh and sums whos first argument is a sumn are contains two typos.

[rwst]

comment:6

Replying to @rwst:

I would call this only if the expression contains sums, test it via e.g.:

sage: ex.has(sum(w,x,1,n,hold=True))
True

Ah sorry that needs #22926 to be able to test for sum(...,w,....).

[EmmanuelCharpentier]

comment:7

Replying to @rwst:

I would call this only if the expression contains sums, test it via e.g.:

sage: w=SR.wild()
sage: ex = sum(x+x^2,x,1,n,hold=True)
sage: ex.has(sum(w,x,1,m,hold=True))
False
sage: ex.has(sum(w,x,1,n,hold=True))
True

Indeed. But isn't that more expensive than directly testing for the operator being sum (and recurse) ?

Minor cosmetics would be to give ES a more descriptive name.

Will do (maybe : see below). But that's only an internal subfunction.

Also you need spaces after commata, semicola, and around equal signs for convention.

OK. (I'm probably the worst typist in the world...).

Finally please test if your documentation builds, the doctest spacing looks wrong. Oh and sums whos first argument is a sumn are contains two typos.

Indeed...

But I'm beginning to have misgivings. "Distribute symbolic sums over sums" isn't lthe only case where this might be useful. We have also :

• Distribute symbolic products over products (when we have symbolic products...).
• Distribute sums (symbolic and add_vararg) over derivation (I currently get nonsense, BTW...)
• Ditto for integration.
  and I may forget other "obvious" cases which are not obvious to me...

I'm starting to think that we may need a distribute method (with possibly optional arguments allowing to specify what should distributed over what), rather than (over)-extending the expand method.

What do you think ? I'm setting this ticket to needs_work while expecting your comments

[rwst]

comment:8

Replying to @EmmanuelCharpentier:

I'm starting to think that we may need a distribute method (with possibly optional arguments allowing to specify what should distributed over what), rather than (over)-extending the expand method.

I don't object.

[EmmanuelCharpentier]

comment:9

Replying to @rwst:

Replying to @EmmanuelCharpentier:

I'm starting to think that we may need a distribute method (with possibly optional arguments allowing to specify what should distributed over what), rather than (over)-extending the expand method.

I don't object.

Created #22937. I'll make an inital proposal there (not quite soon, alas...). I'll also post something on sage-devel.

[sagetrac-robert-dodier]

comment:10

For what it's worth, Maxima has declare(foo, additive) (also outative and linear) which seems to have the desired effect. E.g.

    (%i2) 'sum(f(i) + g(i), i,1,n);
    (%o2) 'sum(g(i)+f(i),i,1,n)
    (%i3) declare(nounify(sum), additive) $
    (%i4) 'sum(f(i) + g(i), i,1,n);
    (%o4) 'sum(g(i),i,1,n)+'sum(f(i),i,1,n)

That's handled by the global simplifier, so it's all or nothing -- you can't expand one expression and not another. Dunno if that's an issue. Also, this action is purely formal -- if it's an infinite sum, the simplifier happily plows ahead without testing convergence.

There is also a more general mechanism for distributing operators and functions over other operators and functions, via the symbol property DISTRIBUTE_OVER. This is used to distribute some functions over lists, matrices, and equations. The declaration has to be in Lisp, e.g. :lisp (setf (get 'mfoo 'distribute_over) '(mbar mbaz mquux)) which says that operator MFOO distributes over MBAR, MBAZ, and MQUUX. Again the general simplifier puts that declaration into effect.

Anyway, hope that sheds some light.

[fchapoton]

comment:11

Please take take ASAP of the apply/python3 issue introduced in #22937.

[EmmanuelCharpentier]

comment:12

Dear Robert,

Sorry, I didn't see your (quite enlightening) answer until right now (tywo weeks later).

I've implemented (part of) what I want in #22937. But I'll consider comparing tgis implementation with changing the relevant properties on-the-fly to the same effect.

Anyway, the present ticket is abandoned. I just forgot to close it.

Replying to @robert-dodier:

For what it's worth, Maxima has declare(foo, additive) (also outative and linear) which seems to have the desired effect. E.g.

    (%i2) 'sum(f(i) + g(i), i,1,n);
    (%o2) 'sum(g(i)+f(i),i,1,n)
    (%i3) declare(nounify(sum), additive) $
    (%i4) 'sum(f(i) + g(i), i,1,n);
    (%o4) 'sum(g(i),i,1,n)+'sum(f(i),i,1,n)

That's handled by the global simplifier, so it's all or nothing -- you can't expand one expression and not another. Dunno if that's an issue. Also, this action is purely formal -- if it's an infinite sum, the simplifier happily plows ahead without testing convergence.

There is also a more general mechanism for distributing operators and functions over other operators and functions, via the symbol property DISTRIBUTE_OVER. This is used to distribute some functions over lists, matrices, and equations. The declaration has to be in Lisp, e.g. :lisp (setf (get 'mfoo 'distribute_over) '(mbar mbaz mquux)) which says that operator MFOO distributes over MBAR, MBAZ, and MQUUX. Again the general simplifier puts that declaration into effect.

Anyway, hope that sheds some light.

[EmmanuelCharpentier]

comment:13

Replying to @fchapoton:

Please take take ASAP of the apply/python3 issue introduced in #22937.

Indeed (see my answer on #22937).

I forgot to close the present ticket, which I do now (setting its milestone to sage-duplicate/invalid/wontfix and giving it positive review)..

[embray]

comment:14

Closing tickets in the sage-duplicate/invalid/wontfix module with positive_review (i.e. someone has confirmed they should be closed).