[This is not a full response, but too much detail for a comment.]
The general rule is that any integral that can behave differently on a measure zero set in the space of real values of parameters is a candidate for giving a result that will not be what you want. There are other caveats as well, for example in dealing with multiple integrals. And sometimes Integrate
can give provisos that involve restrictions on complex values of parameters.
Some tactics I would recommend are as follows.
(1) Where applicable, use Fourier
instead of Integrate
. It may be better suited for handling such transforms. That is to say, it is generally better suited, though I cannot state for certain that it will handle the cases that cause you difficulty.
Example:
ft = FourierCosTransform[UnitBox[x/(2*Pi)]*Cos[m*x], x, n,
Assumptions -> Element[m, Integers]]
(* ((-1)^m n Sqrt[2/\[Pi]] Sin[n \[Pi]])/(-m^2 + n^2) *)
Note that I do not attempt to restrict the Fourier parameter n
, only the parameter in the integrand. If I also assume that n
is an integer I get the "unwanted" result of zero. But such a restriction on the Fourier parameter itself really is asking for trouble; I think it will be more useful to get the general result and try to manipulate that after the fact (see item (5) below for example).
Having said all that, one can actually get "sensible" results with assumptions on the Fourier parameter, or assumptions of integrality, provided they are sufficiently explicit for the code under the hood to not fall into an unwanted generic result. Here are some variants; the first gives a bad outcome but the others might be seen as viable for the issue at hand.
FourierCosTransform[UnitBox[x/(2*Pi)]*Cos[m*x], x, n,
Assumptions -> Element[{m, n}, Integers]]
(* Out[26]= 0 *)
FourierCosTransform[UnitBox[x/(2*Pi)]*Cos[m*x], x, n,
Assumptions -> Element[{m, n}, Integers] && m == -n]
(* Out[28]= Sqrt[\[Pi]/2] *)
FourierCosTransform[UnitBox[x/(2*Pi)]*Cos[m*x], x, n,
Assumptions -> m == -n]
(* Out[29]= (\[Pi] + Sin[2 n \[Pi]]/(2 n))/Sqrt[2 \[Pi]] *)
(2) If you are dealing with possibly discrete-valued sets (e.g. Integers
), use the Assumptions
option in preference to Assuming
. This is explained here (and thanks to @Szabolcs for dredging up the link).
(3) Give as detailed a set of Assumptions
as possible, subject to not invoking discreteness. As mentioned in my comments to an earlier version of this question, functions Integrate
relies on, such as Refine
, will give a generic result for e.g. Sin[m*Pi]/m
under the assumption Element[m,Integers]
.
(4) It might be worth your time to try to understand those various explanations, and further information at provided links, that you seem to dismiss. Among other potential benefits, they could give insight into what situations for Integrate
are likely to give outcomes you do not want. You might also get a healthy idea of what are the roadblocks a function like Integrate
will face. That in turn might give some guidance as to how to overcome them should you code a myFourierIntegrateSpecialized
to work around the genericity of results.
(5) As has been pointed out, you might need to invoke Limit
on results from Integrate
. If you do code your own special-case integrator, that might be useful for getting Kronecker delta types of results.
(6) Consider using FourierXXXCoefficient
if applicable. Here is an example.
FourierCosCoefficient[Cos[m*x], x, n]
(* Out[40]= (2 (-1)^n m Sin[m \[Pi]])/(m^2 \[Pi] - n^2 \[Pi]) *)
This might then be amenable to further analysis under conditions that m==+-n
and both are integers, say.
If I come up with any other suggestions or guidelines I'll edit them in.
Integrate[Cos[m*x]*Cos[m*x], {x, 0, 2 Pi}, Assumptions -> {Element[m, Integers]}]
and I got a sensible answer. It seems you had a typo inAssumptions
. $\endgroup$Limit
. $\endgroup$