Dumb question about sums

[Emmanuel Charpentier]

I d not understand what is possible and not possible about sums with Sage (and its minions).

I am interested in the symbolic manipulation of a sum of (unspecified) data series X. Since Sage does nott (yet) admits indiced symbolic variable, it is reprsented by a function of an integer argument.

Sage seems unable to show that $\sum_{i=1}^{p+1}X_i-\sum_{i=1}^pX_i==X_{p+1}$ :

sage: var("p,j", domain="integer")
....: assume(p,"integer",j,"integer",p>0)
....: X=function("X")(j)
....: foo(p)=sum(X(j),j,1,p)
....: print foo
....: bool(foo(p+1)-foo(p)==X(p+1))
....:
(p, j)
/usr/local/sage-7/local/lib/python2.7/site-packages/IPython/core/interactiveshell.py:2881: DeprecationWarning: Substitution using function-call syntax and unnamed arguments is deprecated and will be removed from a future release of Sage; you can use named arguments instead, like EXPR(x=..., y=...)
See http://trac.sagemath.org/5930 for details.
  exec(code_obj, self.user_global_ns, self.user_ns)
p |--> sum(X(j), j, 1, p)
False

I understand the warning, and think it's irrelevant. But I do not understand why the "obvious" expansion is not used. Similarly :
sage: (foo(p+1)-foo(p)).maxima_methods().sumcontract()
sum(X(j), j, 1, p + 1) - sum(X(j), j, 1, p)

Am I missing something ?

--
Emmanuel Charpentier

[Nils Bruin]

On Wednesday, December 28, 2016 at 6:18:28 AM UTC-8, Emmanuel Charpentier wrote:

I d not understand what is possible and not possible about sums with Sage (and its minions).

I am interested in the symbolic manipulation of a sum of (unspecified) data series X. Since Sage does nott (yet) admits indiced symbolic variable, it is reprsented by a function of an integer argument.

Sage seems unable to show that $\sum_{i=1}^{p+1}X_i-\sum_{i=1}^pX_i==X_{p+1}$ :

sage: var("p,j", domain="integer")
....: assume(p,"integer",j,"integer",p>0)
....: X=function("X")(j)

You can avoid the warning downstairs by simply setting X=function("X") or (because of the side-effects of toplevel function, just function("X") .

....: foo(p)=sum(X(j),j,1,p)

This has the nasty sideeffect of clobbering "p" (which in your case doesn't make any difference, I think). Calling

foo = sum(x(j),j,1,p).function(p)

has a cleaner result.

....: print foo
....: bool(foo(p+1)-foo(p)==X(p+1))
....:
(p, j)
/usr/local/sage-7/local/lib/python2.7/site-packages/IPython/core/interactiveshell.py:2881: DeprecationWarning: Substitution using function-call syntax and unnamed arguments is deprecated and will be removed from a future release of Sage; you can use named arguments instead, like EXPR(x=..., y=...)
See http://trac.sagemath.org/5930 for details.
  exec(code_obj, self.user_global_ns, self.user_ns)
p |--> sum(X(j), j, 1, p)
False

I understand the warning, and think it's irrelevant. But I do not understand why the "obvious" expansion is not used. Similarly :
sage: (foo(p+1)-foo(p)).maxima_methods().sumcontract()
sum(X(j), j, 1, p + 1) - sum(X(j), j, 1, p)

Am I missing something ?

It seems to me that this is an unnecessary limitation in the maxima routines. It clearly knows something about sum manipulations. Perhaps it's worth reporting to the Maxima tracker. I'm not so sure this will ever be very powerful, though, but the following example shows that some improvements should be within reach:

sage: T=foo(p+1)+foo(p)
sage: T.maxima_methods().sumcontract()
X(p + 1) + 2*sum(X(j), j, 1, p)

It does agree with the documentation of sumcontract, which deals with addition of sums. Apparently, that does not include differences of sums ...
 

--
Emmanuel Charpentier

[Emmanuel Charpentier]

Dear Nils, dear list,

Le mercredi 28 décembre 2016 20:59:50 UTC+1, Nils Bruin a écrit :

On Wednesday, December 28, 2016 at 6:18:28 AM UTC-8, Emmanuel Charpentier wrote:

I d not understand what is possible and not possible about sums with Sage (and its minions).

I am interested in the symbolic manipulation of a sum of (unspecified) data series X. Since Sage does nott (yet) admits indiced symbolic variable, it is reprsented by a function of an integer argument.

Sage seems unable to show that $\sum_{i=1}^{p+1}X_i-\sum_{i=1}^pX_i==X_{p+1}$ :

sage: var("p,j", domain="integer")
....: assume(p,"integer",j,"integer",p>0)
....: X=function("X")(j)

You can avoid the warning downstairs by simply setting X=function("X") or (because of the side-effects of toplevel function, just function("X") .

....: foo(p)=sum(X(j),j,1,p)

This has the nasty sideeffect of clobbering "p" (which in your case doesn't make any difference, I think). Calling

foo = sum(x(j),j,1,p).function(p)

A nice one ! I didn't think of it.

has a cleaner result.

....: print foo
....: bool(foo(p+1)-foo(p)==X(p+1))
....:
(p, j)
/usr/local/sage-7/local/lib/python2.7/site-packages/IPython/core/interactiveshell.py:2881: DeprecationWarning: Substitution using function-call syntax and unnamed arguments is deprecated and will be removed from a future release of Sage; you can use named arguments instead, like EXPR(x=..., y=...)
See http://trac.sagemath.org/5930 for details.
  exec(code_obj, self.user_global_ns, self.user_ns)
p |--> sum(X(j), j, 1, p)
False

I understand the warning, and think it's irrelevant. But I do not understand why the "obvious" expansion is not used. Similarly :
sage: (foo(p+1)-foo(p)).maxima_methods().sumcontract()
sum(X(j), j, 1, p + 1) - sum(X(j), j, 1, p)

Am I missing something ?

It seems to me that this is an unnecessary limitation in the maxima routines. It clearly knows something about sum manipulations. Perhaps it's worth reporting to the Maxima tracker. I'm not so sure this will ever be very powerful, though, but the following example shows that some improvements should be within reach:

sage: T=foo(p+1)+foo(p)
sage: T.maxima_methods().sumcontract()
X(p + 1) + 2*sum(X(j), j, 1, p)

It does agree with the documentation of sumcontract, which deals with addition of sums. Apparently, that does not include differences of sums ...

This is now Maxima's bug 3267. Do you think that a Sage-specific ticket would be usefuil ?

HTH,

--
Emmanuel Charpentier
 

 

--
Emmanuel Charpentier

[Emmanuel Charpentier]

Robert Dodier suggests :

(%i12) sumcontract (intosum (sum(X(i),i,1,n+1)-sum(X(i),i,1,n)));
(%o12)                             X(n + 1)

Indeed :

sage: maxima.sumcontract(maxima.intosum(sum(X(j),j,1,p+1)-sum(X(j),j,1,p))).sage
....: ()
X(p + 1)

But :

sage: (sum(X(j),j,1,p+1)-sum(X(j),j,1,p)).maxima_methods().intosum().maxima_meth
....: ods().sumcontract()

sum(X(j), j, 1, p + 1) - sum(X(j), j, 1, p)

That seems to indicate that relevant methods/functions might be of interest in Sage...

I also note that our use of Maxima's product() is wrong, wrong, wrong :

sage: maxima.product(X(j),j,1,p).sage()
X(j)^p

Mamma mia !!! I'll check the list of known bugs and, if not present, file the relevant ticket.

BTW, a quick look at Sympy's, Mathematica's and Maple's possibilities in this domain seems to indicate that the "sum and products" department has been somewhat neglected.

Similarly, I think that special cases for sums and product could be implemented in log() and exp() (and possibly for (hyperbolic) trig functions). But that needs a bit (!) of further thought...

HTH,

--
Emmanuel Charpentier

[Nils Bruin]

On Friday, December 30, 2016 at 3:43:34 AM UTC-8, Emmanuel Charpentier wrote:

I also note that our use of Maxima's product() is wrong, wrong, wrong :

sage: maxima.product(X(j),j,1,p).sage()
X(j)^p

maxima.sum is equally wrong:

 sage: maxima_calculus.sum(j,j,1,p)
_SAGE_VAR_j*_SAGE_VAR_p

Note that the call procedure here is the one employed for expect interfaces, so it amounts to something like the maxima script:

sage1 :  j
sage2 :  j
sage3 : 1
sage4 : p
sum(sage1,sage2,sage3,sage4)

which indeed results in "j*p"

It looks like sum and product simplify before they evaluate their variables. This is a bug in maxima, not in the sage interface, I would say.

[Nils Bruin]

On Friday, December 30, 2016 at 10:05:19 AM UTC-8, Nils Bruin wrote:

It looks like sum and product simplify before they evaluate their variables. This is a bug in maxima, not in the sage interface, I would say.

Perhaps it's not a bug. It certainly is documented (and indeed, if in sum(T,i,a,b) the variable i would evaluate to anything that is not a variable, we'd get an error. On the other hand, if i is bound to something then it will be hard for T to have any references to i in it. So there is a scoping issue here: the counting variable needs to be not bound.

In any case, if we want support for products we should do that via the same mechanism used for sums (i.e., via an intermediate sr_prod function that takes care of efficient and correct translation to maxima)

[Emmanuel Charpentier]

Nils,

Something *is* fishy here. Annotated but unedited transcript :

charpent@asus16-ec:~$ sage
┌────────────────────────────────────────────────────────────────────┐
│ SageMath version 7.5.rc1, Release Date: 2016-12-28                 │
│ Type "notebook()" for the browser-based notebook interface.        │
│ Type "help()" for help.                                            │
└────────────────────────────────────────────────────────────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Warning: this is a prerelease version, and it may be unstable.     ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
sage: var("j,p",domain="integer")
(j, p)
sage: sum(j,j,1,p)
1/2*p^2 + 1/2*p

This is what one expects from sage...

sage: maxima("sum(j,j,1,p)").sage()
sum(j, j, 1, p)

This is what is expected from Maxima, as long as simpsum is not true (default)

sage: maxima.sum(j,j,1,p).sage()
j*p

This is sheer, chemically pure (analytical quality) madness.

sage: maxima_calculus(sum(j,j,1,p)).sage()
1/2*p^2 + 1/2*p

This is mathematically correct, and show that the maxima_calculus interface somehow does (temporarily) sets simpsum.
Note the syntax I employed : the call is the argument of maxima_calculus, not a method...

sage: %%maxima
....: sum(j,j,1,p);
....:
'sum(j,j,1,p)

As expected from Maxima.

sage: %%maxima
....: sum(j,j,1,p),simpsum;
....:
(p^2+p)/2

Again, as expected.

sage: maxima_calculus.sum(j,j,1,p).sage()
j*p

Madness again. This time, this is a method call...

Compare :

sage: maxima_calculus.sumcontract(maxima_calculus.intosum(sum(X(j),j,1,p+1)-sum(
....: X(j),j,1,p))).sage()
X(p + 1)

sage: maxima.sumcontract(maxima.intosum(sum(X(j),j,1,p+1)-sum(X(j),j,1,p))).sage
....: ()
X(p + 1)

Same difference... However, this tends to show that the madness is on *our* side...

Le vendredi 30 décembre 2016 19:05:19 UTC+1, Nils Bruin a écrit :

On Friday, December 30, 2016 at 3:43:34 AM UTC-8, Emmanuel Charpentier wrote:

I also note that our use of Maxima's product() is wrong, wrong, wrong :

sage: maxima.product(X(j),j,1,p).sage()
X(j)^p

Maxima left to its own resources does something acceptable (if not really helpful) :

sage: maxima("product(X(j),j,1,p);")
'product(X(j),j,1,p)

 

maxima.sum is equally wrong:

 sage: maxima_calculus.sum(j,j,1,p)
_SAGE_VAR_j*_SAGE_VAR_p

No. That's Sage interpretation of what Maxima does with what Sage sends it. Typed directly (on command line, in a %%maxima cell or in a maxima("...") call), Maxima returns what's expected. My conclusion is that Sage either sends cat food to Maxima or does dog food with what Maxima sends bacl
k. In both cases, that's a bit unappetizing...

Note that the call procedure here is the one employed for expect interfaces, so it amounts to something like the maxima script:

sage1 :  j
sage2 :  j
sage3 : 1
sage4 : p
sum(sage1,sage2,sage3,sage4)

which indeed results in "j*p"

Huh ? How do you reach this conclusion ?

It looks like sum and product simplify before they evaluate their variables. This is a bug in maxima, not in the sage interface, I would say.

I'm afraid I can't agree (see above). Unless I'm missing your point entirely, which is, of course, possible...

HTH,

--
Emmanuel Charpentier

[Nils Bruin]

On Friday, December 30, 2016 at 3:54:08 PM UTC-8, Emmanuel Charpentier wrote:

This is what one expects from sage...

sage: maxima("sum(j,j,1,p)").sage()
sum(j, j, 1, p)

This is what is expected from Maxima, as long as simpsum is not true (default)

sage: maxima.sum(j,j,1,p).sage()
j*p

This is sheer, chemically pure (analytical quality) madness.

 

This is simply because the generic "expect interface" call amounts to executing something along the lines

sage1 :  j
sage2 :  j
sage3 : 1
sage4 : p
sum(sage1,sage2,sage3,sage4)

which works fine for most function calls in maxima, but not for sum and prod, where it is specified that the second parameter is *not* evaluated. So you end up with evaluating sum(j,sage2,1,p) [where the binding of sage2 is ignored].

sage: maxima_calculus.sum(j,j,1,p).sage()
j*p

Madness again. This time, this is a method call...

Same code. It's a matter of legacy that maxima_lib evaluates its function calls this way. It would be easy to make more efficient. In any case, it means that maxima functions that have special evaluation rules for their arguments will NOT be called correctly.
 
Indeed, it's not maxima's fault. However, maxima.sum and maxima.prod are just there as generic things. We can't really expect the generic code to divine the special evaluation rules. It would make sense to remove the intermediate variables from the maxima_lib code. They are really quite unnecessary there.