infinite sums that are infinite produce errors

[dkrenn]

Look at the following code:

sage: m = var('m')
sage: sum(m, m, 0, oo)
Traceback (most recent call last):
...
ValueError: Computation failed since Maxima requested additional
constraints; using the 'assume' command before summation *may* help
(example of legal syntax is 'assume(m>0)', see `assume?` for more 
details)
Is  m  positive or zero?

But inside the sum, it should be clear what m is. Using one of or both of the commands

sage: assume(m>=0) 
sage: assume(m, 'integer')

does not change the result. Execution of

sage: maxima.sum(m, m, 0, oo)

results in the same (except that a TypeError is thrown).

A different behaviour brings the following example

sage: m = var('m')
sage: sum(2^m, m, 0, oo)
Traceback (most recent call last):
...
ValueError: Sum is divergent.

Whereas

sage: maxima.sum(2^m, m, 0, oo)
inf

[kcrisman]

Short story is that there are many things like this in Maxima. See #3732, for example. This is a good ticket, but to be fair, it is nearly impossible to guarantee that these interactions will never happen - the Maxima devs would rightly point out that figuring out when all forms will be equivalent is not decidable in polynomial time or something like that.

I'm moving the other one to #11987, as it's almost certainly the same problem.

[kcrisman]

Upon further reflection, what are we seeking for in the second example (which has absolutely nothing to do with #11987, since it really does diverge, my apologies!)? I think that Sage just agrees to raise errors for divergent integrals and sums, not infinity, so the behavior is correct from that point of view.

Otherwise this is another example of #3732, unfortunately.

[burcin]

I don't see what the expected behavior here is. Do you want sum() to return infinity instead of raising a ValueError with the message Sum is divergent.?

Note that if you state that the variable is positive, the first example also raises an error:

sage: n = var('n')
sage: assume(n>0)
sage: sum(n, n, 0, infinity)
...
ValueError: Sum is divergent.

[kcrisman]

Burcin, if you agree with me on this (that raising an error is appropriate), then perhaps this should be closed as wontfix? Or should we change all sums and integrals which really do "diverge monotonically to infinity" (as opposed to some other kind of divergence) to return oo?

[dkrenn]

If we know that a sum diverge monotonically to infinity, then the output should say that, i.e. should be oo.

The reason I open the ticket is, that all sums above have the same behavior, but the output is always different, which should not be.

And, I don't see (from a user point of view) any reason, that in

sum(m, m, 0, oo)

Sage asks "Is m positive or zero?" and in

sum(2^m, m, 0, oo)

not.

[kcrisman]

If we know that a sum diverge monotonically to infinity, then the output should say that, i.e. should be oo.

Well, that is the question.

The reason I open the ticket is, that all sums above have the same behavior, but the output is always different, which should not be.

Well, maxima.sum is not really applicable, because that is a Maxima element. That's sort of like complaining that mpmath returns mpf numbers - you aren't asking for a Sage element. So it still sort of reverts to the big question.

And, I don't see (from a user point of view) any reason, that in

sum(m, m, 0, oo)

Sage asks "Is m positive or zero?" and in

I'll note that now Sage (via Maxima) asks "Is m positive, negative, or zero?"

sum(2^m, m, 0, oo)

not.

Right, as I said in comment:1, there are lots of things like this in Maxima (extra interactions). We can report it upstream, but it may be that the algorithm they use just has to ask this.

It sounds like you're motivated on this one, and certainly it would be great to get the right error and not the question.

(%i6) load(simplify_sum);
(%o6) /Users/.../sage-5.2/local/share/maxima/5.26.0/share/c\
ontrib/solve_rec/simplify_sum.mac
(%i7) simplify_sum(sum(m,m,0,inf));
Is  m  positive, negative, or zero?
(%i3) assume(m>0);
(%o3)                               [m > 0]
(%i4) simplify_sum(sum(m,m,0,inf));

sum: sum is divergent.
#0: simplify_sum(expr='sum(m,m,0,inf))
 -- an error. To debug this try: debugmode(true);

You could ask about this on the Maxima list or report it on their tracker! Incidentally,

sage: var('m')
m
sage: assume(m>0)
sage: sum(m,m,0,oo)

ValueError: Sum is divergent.

so something must have changed in the meantime.

[burcin]

Replying to kcrisman:

The reason I open the ticket is, that all sums above have the same behavior, but the output is always different, which should not be.

Well, maxima.sum is not really applicable, because that is a Maxima element. That's sort of like complaining that mpmath returns mpf numbers - you aren't asking for a Sage element. So it still sort of reverts to the big question.

Exactly. The behavior of the sum() function in Sage is consistent. maxima.sum() is just a wrapper to call Maxima. That is also consistent with Maxima behavior.

The expression sum(m, m, 0, oo) is divergent if m != 0 and 0 if m=0. So the best we can do without the assumption Maxima is asking for is to leave it unevaluated.

On the question of shall we raise an error or return oo: Leaving aside the problem that it is usually not that easy to decide which type of infinity to return, I would like to get an error as soon as a divergent sum is encountered. If this expression was part of a larger one, and we decide that its divergent after a substitution, there isn't much point in carrying on evaluating the expression.

In Sage there is one exception to this rule, we return different types of infinity from special functions if you hit a pole. For example gamma(-1) -> Infinity. This is compatible with MMA, although it contradicts Maple or GiNaC. This allows us to do (1/gamma(n)).subs(n=-1) -> 0 instead of raising an error. Compared to what goes on when evaluating sum(), gamma() is a fundamental operation. This convenience to avoid special casing potential poles of gamma() is well worth the bug hunting after a complex expression ends up evaluating to oo.

Since we already have a ticket about handling interactive prompts from Maxima, I suggest we close this ticket.

[kcrisman]

Exactly. The behavior of the sum() function in Sage is consistent. maxima.sum() is just a wrapper to call Maxima. That is also consistent with Maxima behavior.

Yes.

The expression sum(m, m, 0, oo) is divergent if m != 0 and 0 if m=0. So the best we can do without the assumption Maxima is asking for is to leave it unevaluated.

Well, I don't know about this. In some sense, this should be a "dummy variable" in which case the sum is clearly 0+1+2+... but for consistency perhaps this is okay in our case. Otherwise I do agree with dkrenn that sum(2^m, m, 0, oo) should also be asking a question. But this would be an upstream issue, more or less.

On the question of shall we raise an error or return oo: Leaving aside the problem that it is usually not that easy to decide which type of infinity to return, I would like to get an error as soon as a divergent sum is encountered. If this expression was part of a larger one, and we decide that its divergent after a substitution, there isn't much point in carrying on evaluating the expression.
Since we already have a ticket about handling interactive prompts from Maxima, I suggest we close this ticket.

I guess I would be interested in whether Maxima considers the discrepancy between sum(2^m, m, 0, oo) and sum(m, m, 0, oo) behavior is a bug. After all, m should really be a dummy variable! I've actually sent an email and so request to not close this ticket, since this is a (slightly) different issue than the overall issue of Maxima giving interactive prompts. After all, Maxima's integrate(m,m,0,inf) doesn't ask such a question, but says it's divergent.

[robert_dodier]

I've pushed 07a0c810eade (to Maxima Git repo) which changes the behavior of ev(sum(m, m, 0, inf), simpsum=true) so that it immediately reports "sum is divergent" without asking about the sign of m. I believe this clears up the superfluous asksign which Sage bumped into.

This change will appear in the next version (5.29) of Maxima, which is scheduled for early December 2012.

[kcrisman]

Great! Can you put a link to that here, Robert? I'm having trouble getting a link to that change set when I browse the Sourceforge git thing - probably just not familiar with the interface, my apologies.

[robert_dodier]

​http://sourceforge.net/p/maxima/code/ci/07a0c810eade1d26565e477ab17aa2a6121f875e/ seems to be a suitable link.

[kcrisman]

This should get fixed whenever we upgrade to upstream, which is now 5.29.1. I'm putting 'needs work' for that and of course making a patch to check that this works now.

[pbruin]

Since this has now been fixed, all we need to do is to add a doctest.

[git]

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

​b95820a

Trac 11990: doctest for divergent sum error

[tscrim]

LGTM