14

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.

Jerry Guern
  • 4,602
  • 18
  • 47
  • 7
    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. – Hector Dec 01 '14 at 21:16
  • @Hector, I reworded that part. The error happens for Cos[n*x]Cos[mx] because MMa ignores the special case m == n. – Jerry Guern Dec 01 '14 at 21:32
  • Could you amend your question and point out the specific wrong results you get? The $n=m$ case can be handled with Limit. – Szabolcs Dec 01 '14 at 21:33
  • @rm-rf I clarified the question. – Jerry Guern Dec 01 '14 at 21:35
  • @Szabolcs I get wrong results in each of the case I listed. And I know Limit will fix the problem if I happened to know that f[x] was a Cos[], but I usually won't know what f[x] is beforehand, so I need a general method that anticipates and handles these problems. – Jerry Guern Dec 01 '14 at 21:39
  • 1
    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. – Sjoerd C. de Vries Dec 01 '14 at 21:48
  • @SjoerdC.deVries True about the "infinitely large", can't handle them all. But it's bizarre and inexplicable to me that Wolfram wouldn't have designed MMa to handle THESE to cases correctly, given that they are the entire basis of Fourier Analysis and hence cornerstones of EE and SigProc. – Jerry Guern Dec 01 '14 at 21:52
  • Not trying to make any sort of point here, I was just curious how other systems would handle the basic $\int_0^{2\pi} \cos nx ; \cos mx ; dx$, $n,m \in \mathbb{Z}$ example. Here's Maple and MuPad. – Szabolcs Dec 01 '14 at 23:45
  • @Szabolcs Thats certainly an interesting route taken by Maple and MuPad. That said, I do not foresee Mathematica also going that way unless and until we do one of two things. (1) Make some changes at a fairly deep level to Refine and related functions that use Assumptions. (2) Make some fairly deep changes in Integrate to bypass much of the assumptions handling in the presence of explicit assumptions of integrality. – Daniel Lichtblau Dec 01 '14 at 23:56
  • @Daniel They're still not doing well enough to satisfy the complaint here. MuPad figures out the $\cos mx ; \cos nx$ case but not the $e^{ix}\cos mx$ one. Maple simplifies straight to 0, ignoring the possibility of $m=n$ or $m=1$. – Szabolcs Dec 02 '14 at 00:07
  • @Scabolcy Did you try FriCAS or Open-Axiom? Axiom ( aka ScratchPad) had a clean type design (theoretically; in practice it is quite hard to get anything non-purely mathematical done). – Rolf Mertig Dec 02 '14 at 00:30
  • fyi, this is what Maple gives for Integrate[Cos[m*x]*Cos[n*x], {x, 0, 2 Pi}, Assumptions -> Element[{m, n}, Integers]] Mathematica graphics but one has to use the AllSolutions to get this. – Nasser Dec 02 '14 at 00:47
  • @RolfMertig I didn't manage to run either on my machine (OS X). Here's maxima instead (gives 0) and sympy (best result so far, but very slow). – Szabolcs Dec 02 '14 at 01:21

1 Answers1

20

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

Daniel Lichtblau
  • 58,970
  • 2
  • 101
  • 199
  • 1
    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? http://mathematica.stackexchange.com/q/67140/12 – Szabolcs Dec 02 '14 at 19:18
  • 1
    @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. – Daniel Lichtblau Dec 02 '14 at 20:31