The current git version returns your result in %o47 in all cases.
What version are your running?
As it can be seen in the attached image (maxima session within TeXmacs), maxima gives the generic result 0 when asked to compute
integrate(sin(n*x)*sin(p*x),x,0,%pi)
for integers n,p>0, which is correct, EXCEPT that in the case n=p the correct result is %pi/2.
The current git version returns your result in %o47 in all cases.
What version are your running?
Hello, Raymond. Thak you for reacting so rapidly.
On 31/10/2013 15:53, Raymond Toy wrote:
The current git version returns your result in %o47 in all cases.
Do you mean even after indicating that n and p are positive integers?
What version are your running?
Sorry, I didn't give that basic information:
Maxima version: 5.20.1
Maxima build date: 8:48 2/16/2010
Host type: i686-pc-linux-gnu
Lisp implementation type: GNU Common Lisp (GCL)
Lisp implementation version: GCL 2.6.7
I usually kept my Ubuntu 10 updated...
Thank you again for the attention. Of course, I would like to know if
you consider it a bug, and if/when it's repaired.
Best regards,
[bugs:#2652] integrate(sin(nx)sin(p*x),x,0,%pi) fail to consider n=p case
Status: open
Created: Thu Oct 31, 2013 01:13 AM UTC by SouForje
Last Updated: Thu Oct 31, 2013 01:13 AM UTC
Owner: nobodyAs it can be seen in the attached image (maxima session within TeXmacs), maxima gives the generic result 0 when asked to compute
integrate(sin(nx)sin(p*x),x,0,%pi)
for integers n,p>0, which is correct, EXCEPT that in the case n=p the correct result is %pi/2.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/maxima/bugs/2652/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Sorry, it looks like I made some kind of mistake. I get 0 now. I don't know what I did.
My guess is that because maxima knows that n and p are integers, maxima immediately simplifies sin(n%pi) and sin(m%pi) immediately to 0.
To be precise, my installed package is
maxima-src 5.20.1-5ubuntu1
A computer algebra system -- source code
Maxima is a fully symbolic computation program. It is full featured
doing symbolic manipulation of polynomials, matrices, rational
functions, integration, Todd-coxeter methods for finite group
analysis, graphing, multiple precision floating point computation.
It has a symbolic source level debugger for maxima code. Maxima is
based on the original Macsyma developed at MIT in the 1970s. It is
quite reliable, and has good garbage collection, and no memory leaks.
It comes with hundreds of self tests.
This package contains the lisp source code.
Canonical does not provide updates for maxima-src. Some updates may be
provided by the Ubuntu community.
On 31/10/2013 23:09, jfortes wrote:
Hello, Raymond. Thak you for reacting so rapidly.
On 31/10/2013 15:53, Raymond Toy wrote:
The current git version returns your result in %o47 in all cases.
Do you mean even after indicating that n and p are positive integers?
What version are your running?
Sorry, I didn't give that basic information:
Maxima version: 5.20.1
Maxima build date: 8:48 2/16/2010
Host type: i686-pc-linux-gnu
Lisp implementation type: GNU Common Lisp (GCL)
Lisp implementation version: GCL 2.6.7I usually kept my Ubuntu 10 updated...
Thank you again for the attention. Of course, I would like to know if
you consider it a bug, and if/when it's repaired.Best regards,
- José Fortes
[bugs:#2652] integrate(sin(nx)sin(p*x),x,0,%pi) fail to consider
n=p caseStatus: open
Created: Thu Oct 31, 2013 01:13 AM UTC by SouForje
Last Updated: Thu Oct 31, 2013 01:13 AM UTC
Owner: nobodyAs it can be seen in the attached image (maxima session within
TeXmacs), maxima gives the generic result 0 when asked to computeintegrate(sin(nx)sin(p*x),x,0,%pi)
for integers n,p>0, which is correct, EXCEPT that in the case n=p the
correct result is %pi/2.
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/maxima/bugs/2652/To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
I tried replying to this bug by email and nothing seems to have happened, so maybe that doesn't work. So I'm pasting in the text again. If there's some massive time delay, and we end up with two copies then I'll delete one (and sorry for spamming subscribers to the bug!) The "email" follows:
This looked interesting, so I had a quick look at my end. It looks like
the definite integral is done by taking limits of an indefinite one:
Maxima 5.31.3 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.9 (a.k.a. GCL) 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) declare (n, integer); (%o1) done (%i2) declare (p, integer); (%o2) done (%i3) integrate (sin(n*x), x, 0, %pi); n 1 (- 1) (%o3) - - ------ n n (%i4) integrate (sin(n*x)*sin(p*x), x, 0, %pi); (%o4) 0 (%i5) ?trace(?sinint); (%o5) (sinint) (%i6) integrate (sin(n*x)*sin(p*x), x, 0, %pi); 1> (SININT ((MTIMES SIMP) ((%SIN SIMP) ((MTIMES SIMP) $N $X)) ((%SIN SIMP) ((MTIMES SIMP) $P $X))) $X) <1 (SININT ((MPLUS SIMP) ((MTIMES SIMP) ((RAT SIMP) 1 2) ((MEXPT SIMP) ((MPLUS SIMP) $N ((MTIMES SIMP) -1 $P)) -1) ((%SIN SIMP) ((MTIMES SIMP) ((MPLUS SIMP) $N ((MTIMES SIMP) -1 $P)) $X))) ((MTIMES SIMP) ((RAT SIMP) -1 2) ((MEXPT SIMP) ((MPLUS SIMP) $N $P) -1) ((%SIN SIMP) ((MTIMES SIMP) ((MPLUS SIMP) $N $P) $X))))) (%o6) 0 (%i7) ?trace(?defint); (%o7) (defint) (%i8) integrate (sin(n*x)*sin(p*x), x, 0, %pi); 1> (DEFINT ((MTIMES SIMP) ((%SIN SIMP) ((MTIMES SIMP) $N $X)) ((%SIN SIMP) ((MTIMES SIMP) $P $X))) $X 0 $%PI) 2> (SININT ((MTIMES SIMP) ((%SIN SIMP) ((MTIMES SIMP) $N $X)) ((%SIN SIMP) ((MTIMES SIMP) $P $X))) $X) <2 (SININT ((MPLUS SIMP) ((MTIMES SIMP) ((RAT SIMP) 1 2) ((MEXPT SIMP) ((MPLUS SIMP) $N ((MTIMES SIMP) -1 $P)) -1) ((%SIN SIMP) ((MTIMES SIMP) ((MPLUS SIMP) $N ((MTIMES SIMP) -1 $P)) $X))) ((MTIMES SIMP) ((RAT SIMP) -1 2) ((MEXPT SIMP) ((MPLUS SIMP) $N $P) -1) ((%SIN SIMP) ((MTIMES SIMP) ((MPLUS SIMP) $N $P) $X))))) <1 (DEFINT 0) (%o8) 0 (%i9) integrate (sin(n*x)*sin(p*x), x); 1> (SININT ((MTIMES SIMP) ((%SIN SIMP) ((MTIMES SIMP) $N $X)) ((%SIN SIMP) ((MTIMES SIMP) $P $X))) $X) <1 (SININT ((MPLUS SIMP) ((MTIMES SIMP) ((RAT SIMP) 1 2) ((MEXPT SIMP) ((MPLUS SIMP) $N ((MTIMES SIMP) -1 $P)) -1) ((%SIN SIMP) ((MTIMES SIMP) ((MPLUS SIMP) $N ((MTIMES SIMP) -1 $P)) $X))) ((MTIMES SIMP) ((RAT SIMP) -1 2) ((MEXPT SIMP) ((MPLUS SIMP) $N $P) -1) ((%SIN SIMP) ((MTIMES SIMP) ((MPLUS SIMP) $N $P) $X))))) sin((n - p) x) sin((p + n) x) (%o9) -------------- - -------------- 2 (n - p) 2 (p + n) (%i10)
I think the problem is that substitituting x=%pi or x=0 in the above
gives zero. Which is fine, except when n-p = 0.
Rupert
On 31/10/2013 23:46, Raymond Toy wrote:
Sorry, it looks like I made some kind of mistake. I get 0 now. I don't know what I did.
Thank you for recognizing this immediately, I was going right now trying
to manually install the latest version (which of course is always a good
idea), but now I see that it's low priority, and I'll go instead to my
online course on quantum mechanics!
My guess is that because maxima knows that n and p are integers, maxima immediately simplifies sin(n%pi) and sin(m%pi) immediately to 0.
I see. But the fact that the denominator may be 0 when n=m should
trigger, I think, to consider separetely that particular case /in the
original integral/. Of course, I don't know if that's easy or feasible.
Thank you again!
[bugs:#2652] integrate(sin(nx)sin(p*x),x,0,%pi) fail to consider n=p case
Status: open
Created: Thu Oct 31, 2013 01:13 AM UTC by SouForje
Last Updated: Thu Oct 31, 2013 03:53 PM UTC
Owner: nobodyAs it can be seen in the attached image (maxima session within TeXmacs), maxima gives the generic result 0 when asked to compute
integrate(sin(nx)sin(p*x),x,0,%pi)
for integers n,p>0, which is correct, EXCEPT that in the case n=p the correct result is %pi/2.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/maxima/bugs/2652/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
José,
thanks for reporting this bug with integrate. As it might take some time to be fixed, in the meantime that kind of problem can be avoided as follows:
(%i2) r: integrate(sin(n*x)*sin(p*x),x,0,%pi); (%o2) -((p-n)*sin(%pi*p+%pi*n)+(-p-n)*sin(%pi*p-%pi*n))/(2*p^2-2*n^2) (%i3) s: limit (r,n,p); (%o3) %pi/2-sin(2*%pi*p)/(4*p) (%i4) declare(p,integer)$ (%i5) ev(s); (%o5) %pi/2
Cheers,
Jaime
Diff:
--- old +++ new @@ -1,5 +1,5 @@ As it can be seen in the attached image (maxima session within TeXmacs), maxima gives the generic result 0 when asked to compute -integrate(sin(n*x)*sin(p*x),x,0,%pi) + integrate(sin(n*x)*sin(p*x),x,0,%pi) for integers n,p>0, which is correct, EXCEPT that in the case n=p the correct result is %pi/2.
OK! Thanks, Jaime. Saludos -José
If anyone was curious, Maple 16 and Mathematica 8 have the same bug!
This is not to say that it shouldn't be repaired in Maxima!
Moreover, Matlab 8 has the same bug, too! (both in command window and in MuPAD).
A duplicate of this bug was reported as [bugs:#2686]. I'm closing that one and linking to this as the "master".
Minor update. The bug is still present in Maxima 5.37.
Related examples from the mailing list today:
declare(n, integer); assume(n>0); integrate(sin(t)*sin(n*t), t, 0, %pi); 0 integrate(sin(t)^2, t, 0, %pi); %pi/2
"If I only use assume(n>0)
, I get
-sin(%pi*n)/(n^2-1)
which is wrong as well for n=1."
Both the definite and indefinite integral are computed via MONSTERTRIG in src/sin.lisp. I see that MONSTERTRIG just returns a formula without putting any conditions or qualifications on the result, and the caller (somewhere downstream from SININT) doesn't check the result to verify that it is valid in all cases.
There are at least a couple of directions to go here. (1) MONSTERTRIG could call asksign on the parameters in the formula it returns. That would ensure at least one correct result. (2) MONSTERTRIG could return a list of results, with conditions attached. Callers would have to be ready to handle multiple return values.
I like (2) better, although (1) is simpler, and more consistent with existing behavior.
Log in to post a comment.