#8728 closed defect (fixed)
doctest fixed integral from Maxima
Reported by:  kcrisman  Owned by:  burcin 

Priority:  major  Milestone:  sage7.4 
Component:  calculus  Keywords:  
Cc:  Merged in:  
Authors:  Ralf Stephan  Reviewers:  Travis Scrimshaw 
Report Upstream:  N/A  Work issues:  
Branch:  d4b0db5 (Commits)  Commit:  
Dependencies:  Stopgaps: 
Description (last modified by )
This is fixed now and needs a doctest:
From #sagedevel:
Boulemans left the chat room. (Read error: Connection reset by peer) [11:58am] Boule joined the chat room. [11:58am] Boule: (laptop shutdown due to power supply) [11:59am] Boule: e, T, w = var("e T w"); assume(1 = e^2)>0; integrate(cos(w+T)/(1+e*cos(T))^2,T,0,2*pi) should give 2*pi e cos w/(1e^2)^3/2 instead of 0 [11:59am] Boule: can someone help? [12:00pm] wjp: yeah, sage seems to have some trouble with this integral. You could try http://groups.google.com/group/sagesupport since the right people don't seem to be here currently [12:00pm] Boule: ok, thanx [12:08pm] kcrisman: By the way, I just tried this and get a hang in Maxima. Can you type the exact commands which lead to an answer of 0? [12:08pm] kcrisman: If I plug something (.5, .75) in for e in Maxima in Sage, I do get zero as an output. [12:12pm] Boule: don't know maxima, but with numerical values for e and w at wolframalfa, it gives something different than 0 [12:13pm] wjp: *nod* maple gives nonzeros too [12:13pm] kcrisman: Can you give the *exact* sequence of commands which yield zero in Sage itself? [12:14pm] Boule: e = var('e') [12:14pm] Boule: T = var('T') [12:14pm] Boule: w = var('w') [12:14pm] baali1 joined the chat room. [12:14pm] baali left the chat room. (Quit: Leaving.) [12:15pm] Boule: assume(1e^2>0) [12:15pm] Boule: integrate(cos(w+T)/(1+e*cos(T))^2,T,0,2*pi) [12:15pm] kcrisman: Okay, that's what I thought. [12:16pm] kcrisman: Okay, it takes a while but I do get 0.
Change History (29)
comment:1 followup: ↓ 6 Changed 7 years ago by
comment:2 Changed 7 years ago by
#8729 may point to a solution.
comment:3 Changed 7 years ago by
Hmm, I forgot about this, and it's true it never got implemented, did it?
comment:4 Changed 7 years ago by
It was fixed about two weeks ago in maxima. There was a new release of maxima a few days agoI'm trying to make an spkg right now.
comment:5 Changed 7 years ago by
Sweet. I haven't been keeping up on the Maxima list lately, thanks.
comment:6 in reply to: ↑ 1 Changed 7 years ago by
Replying to jason:
I wonder if this is another manifestation of this bug:
sage: integrate(sqrt(sin(x)^2+cos(x)^2), x,0,2*pi) pi
I just checked; this ticket isn't the same bug.
comment:7 Changed 7 years ago by
The upgrade to maxima 5.21.1 does not fix this. After #8731:
sage: e, T, w = var("e T w") sage: assume(1e^2>0) sage: integrate(cos(w+T)/(1+e*cos(T))^2,T,0,2*pi) 0
comment:8 Changed 6 years ago by
Maxima 5.23.2 still has this, and we still haven't reported it.
Maxima 5.23.2 http://maxima.sourceforge.net using Lisp SBCL 1.0.24 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) assume(1e^2>0); 2 (%o1) [e < 1] (%i3) integrate(cos(w+T)/(1+e*cos(T))^2,T,0,2*%pi); (%o3) 0
This is now Maxima bug 3211975.
comment:9 Changed 6 years ago by
 Report Upstream changed from Not yet reported upstream; Will do shortly. to Fixed upstream, but not in a stable release.
According to the bug report, this is now fixed. However, some examples may still throw a Lisp error, so we should check out whether that will affect us before saying we're totally fixed when we upgrade.
comment:10 Changed 5 years ago by
Maxima 5.28 is now out.
comment:11 Changed 4 years ago by
See #13973 where this should (?) be fixed, just need a doctest here?
comment:12 Changed 4 years ago by
 Milestone changed from sage5.11 to sage5.12
comment:13 Changed 3 years ago by
 Milestone changed from sage6.1 to sage6.2
comment:14 Changed 3 years ago by
 Milestone changed from sage6.2 to sage6.3
comment:15 followup: ↓ 17 Changed 3 years ago by
In Maxima 5.33.0 (see #13973):
(%i1) assume(e^2<1); 2 (%o1) [e < 1] (%i2) integrate(cos(w+T)/(1+e*cos(T))^2, T, 0, 2*%pi); 2 Is abs(e)  sqrt(1  e )  1 positive, negative or zero? negative; ! 2 ! Is !sqrt(1  e )  1!  abs(e) positive, negative or zero? negative; 2 2 %pi e sqrt(1  e ) cos(w) (%o2)   4 2 e  2 e + 1
This appears to be the correct answer. Note that the answers to both questions are "negative" for all e with 1 < e < 1, so it would be nice if Maxima didn't ask those questions.
comment:16 Changed 3 years ago by
 Milestone changed from sage6.3 to sage6.4
comment:17 in reply to: ↑ 15 Changed 2 years ago by
In Maxima 5.33.0 (see #13973): This appears to be the correct answer. Note that the answers to both questions are "negative" for all e with 1 < e < 1, so it would be nice if Maxima didn't ask those questions.
The thing noted in the message upstream when they closed their ticket
sage: integrate(cos(w+T)/(1+.5*cos(T))^2,T,0,2*pi) <boom>
does still happen, but I think that is a different issue tracked elsewhere here (the usual keepfloat thing).
So... do we have a reasonable test case to add here to confirm this is fixed and close it?
comment:18 Changed 2 years ago by
 Report Upstream changed from Fixed upstream, but not in a stable release. to Fixed upstream, in a later stable release.
comment:19 Changed 2 years ago by
 Description modified (diff)
 Summary changed from Incorrect integral from Maxima to doctest fixed integral from Maxima
Here's the doctest:
sage: assume(1e^2>0) sage: assume(abs(e)sqrt(1e^2)1>0) sage: assume(abs(sqrt(1e^2)1)abs(e)>0) sage: integrate(cos(w+T)/(1+e*cos(T))^2,T,0,2*pi) 2*pi*sqrt(e^2 + 1)*e*cos(w)/(e^4  2*e^2 + 1)
comment:20 Changed 2 years ago by
 Branch set to u/rws/doctest_fixed_integral_from_maxima
comment:21 Changed 2 years ago by
 Commit set to fab73690cd00e86c063be62e578a502267e7db94
 Status changed from new to needs_review
New commits:
fab7369  8728: doctest

comment:22 Changed 2 years ago by
 Status changed from needs_review to needs_work
Your assumptions are contradictory: the first assumption (1  e^2 > 0
) implies the negation of the other two assumptions (see also comment:15).
A fortiori, the other two assumptions (after negating) are actually redundant. It is annoying that we have to add them; ideally, we would only declare this integral to be "fixed" if Maxima did not need the extra two assumptions...
comment:23 Changed 7 months ago by
 Branch changed from u/rws/doctest_fixed_integral_from_maxima to u/rws/8728
comment:24 Changed 7 months ago by
 Commit changed from fab73690cd00e86c063be62e578a502267e7db94 to d4b0db584bb2b67b46a8508058dab4dc731fbbce
 Milestone changed from sage6.4 to sage7.4
 Report Upstream changed from Fixed upstream, in a later stable release. to N/A
 Status changed from needs_work to needs_review
New commits:
d4b0db5  8728: doctest fixed integral from Maxima

comment:25 Changed 7 months ago by
 Reviewers set to Travis Scrimshaw
 Status changed from needs_review to positive_review
comment:26 Changed 7 months ago by
 Branch changed from u/rws/8728 to d4b0db584bb2b67b46a8508058dab4dc731fbbce
 Resolution set to fixed
 Status changed from positive_review to closed
comment:27 Changed 6 months ago by
 Commit d4b0db584bb2b67b46a8508058dab4dc731fbbce deleted
I noticed just now that this ticket has been closed; it seems comment:15 and comment:22 were ignored...
comment:28 followup: ↓ 29 Changed 6 months ago by
That would seem so. I think you are asking for a feature (redundancy of additional assumptions) in Maxima that would warrant a separate ticket. I apologize for not answering earlier.
comment:29 in reply to: ↑ 28 Changed 6 months ago by
Replying to rws:
I think you are asking for a feature (redundancy of additional assumptions) in Maxima that would warrant a separate ticket.
That too, but more importantly I meant the fact that the assumptions that are currently made in the doctest are mutually inconsistent:
assume(1c^2 > 0) assume(abs(c)  sqrt(1c^2)  1 > 0) assume(abs(sqrt(1c^2)1)  abs(c) > 0)
Namely, the first assumption is equivalent to 1 < c < 1
, and on this domain the functions abs(c)  sqrt(1c^2)  1
and abs(sqrt(1c^2)1)  abs(c)
are strictly negative.
There is already some functionality for detecting inconsistent assumptions (e.g. assume(x > 0); assume(x < 0)
raises an error), but it doesn't detect this case.
I wonder if this is another manifestation of this bug: