2

Consider the following Sage code (tested using Sage 8.6):

var('t')
var('a')
t.integrate(t, 0, a) # \int_{0}^{a} t dt

Output (as expected):

t
a
1/2*a^2

Next:

t.integrate(t, 0, 2*a - a^2) # 2*a - a^2 could be positive, negative, non-real(?)

Output (again, no problem):

1/2*a^4 - 2*a^3 + 2*a^2

Now suppose we give Sage a little more information. The following assumptions should guarantee that we're integrating over a real interval, and that the second (or "top") endpoint is strictly greater than the first ("bottom") endpoint. (Though as we have seen, Sage does not really need this information.)

assume(a, 'real')
assume(a > 1/2)
assume(a < 3/2) # now 0 < a < 2, so 2*a - a^2 > 0
t.integrate(t, 0, 2*a - a^2) # hangs, eventually produces RuntimeError

So, .integrate() succeeds when nothing is known about the endpoint, but then fails when given more information.

My Question: Is this desired/expected behavior, or would it be considered a bug?

Personally, I found it surprising: I expected that, if a command worked with no assumptions, then it should still work after adding assumptions (consistent assumptions that only narrow the scope of the problem).

What follows is purely my own speculation; feel free to ignore.

I also get a similar kind of problem if I do the following:

forget()
var('t'); var('a');
assume(a, 'real')
assume(a > 1/2)
assume(a < 3/2)
bool(2*a - a^2 > 0) # RuntimeError

It seems to me that $1/2 < a < 3/2$ implies $0 < a < 2$, which implies that $-a^2 + 2a > 0$. (The graph of the quadratic is a downward-opening parabola, with roots at $0$ and $2$.) I am not surprised that Sage has trouble constructing this argument, so I am not surprised that the bool() command hangs. But unfortunately this seems to break .integrate(), which was working otherwise.

So, I speculate that maybe the .integrate() method, when faced with an integral whose endpoints are known to be real, first tries to figure out which endpoint is greater? But sometimes this process hangs, so the .integrate() process never terminates?

In our case, I think Sage assumes by default that a is complex-valued(?), and then it has no problem with the integral. So it seems like it should still work when a is in the real interval $(1/2, 3/2)$, which after all is a subset of $\mathbb{C}$.

By the way, the following works just fine:

forget()
var('t'); var('a');
assume(2*a - a^2 > 0)
print(bool(2*a - a^2 > 0))
t.integrate(t, 0, 2*a - a^2)

Edit: Also asked at ask.sagemath.org: https://ask.sagemath.org/question/52382/assumption-seems-to-break-integrate-is-this-a-bug/

Also, the following works:

t.integrate(t, 0, 2*a - a^2, algorithm='sympy')

(Based on guidance from the Sage development team, it seems that the problem is probably something to do with Maxima.)

mathmandan
  • 2,014
  • 1
    Sage does indeed assume variables are complex, though the way Maxima handles this (which handles our integration) is less than ideal for certain situations. You could try algorithm='sympy' in the integration and see what happens. Also try ask.sagemath.org for possibly quicker responses, not a lot of Sage users/devs monitor this tag currently. – kcrisman Dec 18 '20 at 04:20
  • Actually I did try ask.sagemath. But I didn't get an answer there, so eventually I asked the Sage development team. (In fact it appears that you @kcrisman were personally involved in this discussion! This was around July 23-30.) You also suggested that I submit a Trac report, and maybe also report it upstream to the Maxima people, and link to that in the trac report. I recall that I had trouble with that because the Maxima site was down, or something weird like that... Well, eventually I lost interest. Sorry for not submitting the trac report--I guess I still could. – mathmandan Dec 18 '20 at 06:51
  • Haha! I guess it's hard to keep track of all the support requests in the time of pandemic - Maxima's development happens on a different platform too. It would be great to have you still report at least on Trac if you are able. – kcrisman Dec 19 '20 at 14:32
  • 1
    Hi again @kcrisman . Uh, I think this might be fixed! Before filing the Trac report, I thought I'd try an upgrade to the latest version. I installed Sage 9.2 locally on my own Linux machine (Ubuntu 20.04.1 LTS), and I can't reproduce the issue anymore! I also tried running remotely at CoCalc, and the issue was present in Sage 8.9...but there was an option to upgrade and the issue disappeared when I did that. So...problem solved, I guess? Thank you very much for your kind attention! – mathmandan Dec 20 '20 at 03:26

1 Answers1

0

The issue seems to have been fixed in more recent versions of Sage! Based on my experience, it seemed to be a problem in versions 8.6 and 8.9, but not in 9.2. Since upgrading to 9.2 I can no longer reproduce this issue.

If you are experiencing a similar issue, I would recommend upgrading to a current version if possible. (If that is not possible, a couple of work-arounds are suggested in the Question.)

Also, if you are using Sage online through CoCalc it may give you an option to upgrade to a current version. You can check what version you are running, by opening a notebook and executing a

help()

command.

Thank you very much to the Sage Development Team!

mathmandan
  • 2,014