2020-12-20 19:44:14 +0200 received badge ● Nice Answer (source) 2020-12-20 15:42:57 +0200 received badge ● Necromancer (source) 2020-12-20 15:42:57 +0200 received badge ● Self-Learner (source) 2020-12-20 15:42:57 +0200 received badge ● Teacher (source) 2020-12-20 04:41:09 +0200 answered a question Assumption seems to break integrate(); is this a bug? 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! 2020-12-18 07:23:31 +0200 received badge ● Popular Question (source) 2020-12-18 07:23:31 +0200 received badge ● Notable Question (source) 2020-07-17 14:56:35 +0200 received badge ● Good Question (source) 2020-07-16 08:44:48 +0200 received badge ● Nice Question (source) 2020-07-16 00:16:42 +0200 received badge ● Editor (source) 2020-07-14 23:45:22 +0200 received badge ● Student (source) 2020-07-12 23:21:33 +0200 received badge ● Organizer (source) 2020-07-12 01:48:31 +0200 asked a question Assumption seems to break integrate(); is this a bug? 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, 4*a - a^2) # 4*a - a^2 could be positive, negative, non-real(?)  Output (again, no problem): 1/2*a^4 - 4*a^3 + 8*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) assume(a < 3) # now 0 < a < 4, so 4*a - a^2 > 0 t.integrate(t, 0, 4*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) assume(a < 3) bool(4*a - a^2 > 0) # hangs, RuntimeError  It seems to me that $1 < a < 3$ implies $0 < a < 4$, which implies that $-a^2 + 4a > 0$. (The graph of the quadratic is a downward-opening parabola, with roots at $0$ and $4$.) I am not surprised that Sage has trouble constructing this argument, so I am not surprised that the bool() command hangs. But unfortunately this also 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, 3)$, which after all is a subset of $\mathbb{C}$. By the way, the following works just fine: forget() var('t'); var('a'); assume(4*a - a^2 > 0) print(bool(4*a - a^2 > 0)) t.integrate(t, 0, 4*a - a^2)  Or, this also works: t.integrate(t, 0, 2*a - a^2, algorithm='sympy')  Asked also at Math Stackexchange, but did not receive an answer there. Apologies if this kind of cross-posting is frowned upon.