Fourier Analysis and Signal Processing often require these integrals on functions f[x] that won't be known in advance.

t1:= Integrate[(E^(I*x))*f[x],{x,-Infinity,Infinity}];
t2:= Integrate[Cos[m*x]*f[x],{x,0,2Pi}, Assumptions -> {Element[n, Integers]}];

But MMa returns wrong results because it ignores "special" cases

f[x_] = E^-(a*I*x)
f[x_] = Cos[n*x]
f[x_] = a * E^-(a*I*x) + b * Cos[n*x] + c/(1+x^2)

The cosine integral failure happens when n == m. The exponential integral should return a delta function at a=1.

From discussion on related topics, I gather that this is a design issue, not a bug, because MMa isn't designed to return the "nongeneric" solutions.

So, two questions: How can I fix the above code to anticipate the special cases and work around MMa's failures? What other special-case MMa failures do we need to anticipate and code around?

And I wish I didn't have to say this, but please don't post a bunch of barely-related links that don't address THIS question, or a bunch of discussion defending MMa's design decision. I asked two very specific questions.

  • 7
    $\begingroup$ I did 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 in Assumptions. $\endgroup$
    – Hector
    Dec 1, 2014 at 21:16
  • $\begingroup$ @Hector, I reworded that part. The error happens for Cos[nx]*Cos[mx] because MMa ignores the special case m == n. $\endgroup$ Dec 1, 2014 at 21:32
  • $\begingroup$ Could you amend your question and point out the specific wrong results you get? The $n=m$ case can be handled with Limit. $\endgroup$
    – Szabolcs
    Dec 1, 2014 at 21:33
  • $\begingroup$ @rm-rf I clarified the question. $\endgroup$ Dec 1, 2014 at 21:35
  • 1
    $\begingroup$ I have a hunch that the set of special cases is infinitely large, so there's probably no general method to handle them all. It may be possible to anticipate a restricted set of known cases though. $\endgroup$ Dec 1, 2014 at 21:48

1 Answer 1


[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.


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.

  • 1
    $\begingroup$ I'm not sure if you worked on the symbolic eigenvector solver, could you take a look at this performance regression between M9 and M10? mathematica.stackexchange.com/q/67140/12 $\endgroup$
    – Szabolcs
    Dec 2, 2014 at 19:18
  • 1
    $\begingroup$ @Szabolcs In the course of combating intermediate swell, there are heuristics to consider in terms of when to use things like Expand or Together. These may be used in order to tease out "nice(r)" intermediate forms of expressions. I think I prefer the speed regression in this instance to the alternative, which would have slightly larger problems hanging entirely. $\endgroup$ Dec 2, 2014 at 20:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.