InverseFourierCosTransform

Question

As a following one of my previous question, I have a function about Z and take an InverseFourierTransform of it as:

K1[Z_] = (3 (1 - 4 Z^2))/(2 (1 + Z^2)^(7/2))
K2[t_] = InverseFourierCosTransform[K1[Z], Z, t] // Simplify

Then, I take K2[t_] back by using FourierCosTransform as:

K3[Z_] = FourierCosTransform[K2[t], t, Z] // Simplify

I also test an alternative way by using FourierCosTransform definition as:

Sqrt[2/Pi]*NIntegrate[K2[t]*Cos[0.1*t], {t, 0, Infinity}, PrecisionGoal -> 3, Method -> {"LocalAdaptive"}, MinRecursion -> 5, MaxRecursion -> 10]

Here I set Z=0.l in Cos[] as a test case.

My question is K3[0.1] gives a value of 1.39071, while the numerical integration is not successful, why and how to handle this situation? My overall goal is to get K2[t_] and carry out numerical integration at any point I need. Many thanks to all your help!

Answer 1

With respect to code effiency: In vs 6 the FourierCosTransform have timings of 4 s and 0.2 s. Try vs 13: 7s and 104 s, on a 4* faster machine.

NIntegrate on FourierTransform is a misunderstanding of the idea.

FourierTransform is a concept to generate distributions, multiply them by the FourierTransorm of some smooth functions, with compact support eg, so that the back transformation works, and transform back the product.

If the distribution formally solves an equation, involving only linear combinations of derivatives and integrals, then this object solves the equation and, by definition, at t=0 has the given start value.

Or one multiplies the Fourier transform by a filter and manipulates each color or audio frequency. This is linear invertible filtering by modes.

NIntegrate is never used practically for this purpose, it's to slow.

It is orders of magnitude faster, to transform, on a lattice of Length/2^n, back and forth in real time.

NIntegrate does the same but has not that effective method of Fourier: reducing in fact the algebra to a recursion of calculating differences and sus of next neighbors x_i +- x_i+1 only.

But there is another reason never to use NIntegrate: 99,9999% of all Fourier transforms are calculated by projecting it on the Riemann sphere map of the complex plane (the sphere standing with south pole at z=0 with radius 2, map by rays from the north pole to the plane).

The integral goes over the poles along the image of the real line. If one succeds to find another meridian, yilding an integral of exact zero, one has a closed path, that can be deformed as long as the integrand is analytic.

Finally there remain integrals around poles (z-z_k)^-1, higher order poles don't contibute.

Or there are branch cuts as for square roots of polynomials, than the path will be contracted to encircle the cuts between the zeros under the square root.

In any case, one finally gets a sum over residues, thats the value at the simple poles divided by the jump of the argument from -1 to -1, but on a circle giving 2 pi I as Length independent of the radius.

No NIntegrate can pull out these values from the haystack, if the path is R.

The numerical reason is, that Nintegrate cannot catch up with fast oscillating functions in general.

But the abstract Fourier transforn is exactly doing this by using the Lebesgue integral.

The Lebesgue integral has no problems as long the summed values within a partition, eg in rectangles, of the target complex plane of values, times the volume of thats rectangles pre-images converge.