Difference in FFT between IDL and Python
fft, idl, idl-programming-language, python, scipy
Solution
IDL and numpy use slightly different definitions of the DFT. Numpy's is (from the documentation):
(source: scipy.org)
while IDL's is (from here):
Numpy's `m` is the same as IDL's `x`, `k` is `u`, `n` is `N`. I think `a_m` and `f(x)` are the same thing as well. So the factor of `1/N` is the obvious difference, explaining the difference of 8 in your 8-elt case.
I'm not sure about the 256*8 one for the 256-elt case; could you maybe post the original array and both outputs somewhere? (Does this happen for all 256-elt arrays? What about other sizes? I don't have IDL....)
Problem
I'm passing some simple IDL code to Python. However the returned FFT values form the SciPy/NumPy packages is different than the IDL one and I can't find out why. Reducing it all to a simple example of 8 elements I found that the SciPy/NumPy routines return values that are 8 (2^3) times bigger than the IDL ones (a normalization problem I thought). Here is the example code (copied from here) in both languages: IDL ``` signal = ([-2., 8., -6., 4., 1., 0., 3., 5.]) fourier = fft(signal) print, fourier ``` returns ( 1.62500, 0.00000) ( 0.420495, 0.506282) ( 0.250000, 0.125000) ( -1.17050, -1.74372) ( -2.62500, -0.00000) ( -1.17050, 1.74372) ( 0.250000, -0.125000) ( 0.420495, -0.506282) Python ``` from scipy.fftpack import fft import numpy as N … signal = N.array([-2., 8., -6., 4., 1., 0., 3., 5.]) fourier = fft(signal) print fourier ``` returns [ 13. +0.j , 3.36396103 +4.05025253j, 2. +1.j , -9.36396103-13.94974747j, -21. +0.j , -9.36396103+13.94974747j, 2. -1.j , 3.36396103 -4.05025253j] I did it with the NumPy package and I got the same results. I tried also `print fft(signal, 8 )` just in case but it returned the same, as expected. However that's not all, coming back to my real array of 256 elements I found that the difference was no longer 8 or 256, but 256*8! it's just insane. Although I worked around the problem I NEED to know why there is that difference. Solved: It was just the normalization, at some point I divided the IDL 256 array by a factor of 8 that I forgot to remove. In Dougal's answer there is the documentation that I missed.