## #2652 integrate(sin(nx)sin(p*x),x,0,%pi) fail to consider n=p case

None
open
nobody
5
2015-12-16
2013-10-31
SouForje
No

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.

1 Attachments

## Discussion

<< < 1 2 (Page 2 of 2)
• SouForje - 2013-11-24

Moreover, Matlab 8 has the same bug, too! (both in command window and in MuPAD).

• Rupert Swarbrick - 2014-02-20

A duplicate of this bug was reported as [bugs:#2686]. I'm closing that one and linking to this as the "master".

#### Related

• Robert Dodier - 2015-12-16
• labels: --> integrate, trig

• Robert Dodier - 2015-12-16

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.

<< < 1 2 (Page 2 of 2)