FFT usage / consistency
Hi all, I found myself busy today trying to understand what went wrong in my FFT code. I wrote a minimal example/testing code to check the FFT output against an analytic result and also tried to reverse the transformation to get the original function back. Most curiously, the results depend on whether I first do the fft and then the ifft or the other way round. For the test function, I use the Lorentz function 1/(x^2+1). The exact FT is exp(-|t|)*sqrt(pi/2), the IFT yields the same. 1) First FFT and then IFFT: The real part of FFT oscillates, the imaginary part is not zero, and the magnitudes do not match. All this should not be, but the IFFT reproduces the original function just fine. 2) First IFFT and then FFT: The IFFT is perfect, but the FFT does not reproduce the original function. Could someone please have a look and tell me what I am doing wrong? The code is attached, it also plots the results nicely. Maybe the (corrected) code could be used as an example in the documentation (correct use of (i)fftshift and (i)fftfreq is not trivial!) or as an additional test case. The existing test cases for numpy only seem to check that the fft function can be called, but they do not check consistency of results. I'm using NumPy versions 1.0.4 and 1.1.0 on Linux with fftpack_lite.so (even though fftw3 is installed and configured, but I'll probably ask for that later...) Thanks a lot, Felix
Hi Felix This doesn't look quite right: # Re-Transform to frequency domain fftdata = fftpack.fft(ifftdata) fftdata = fftpack.fftshift(ifftdata) # not the "i" You probably want fftshift(fft(ifftdata))? As an aside, you also don't need vectorise, since those functions are all "vectorised" by themselves. Cheers Stéfan 2008/7/25 Felix Richter <felix@physik3.uni-rostock.de>:
Hi all,
I found myself busy today trying to understand what went wrong in my FFT code. I wrote a minimal example/testing code to check the FFT output against an analytic result and also tried to reverse the transformation to get the original function back. Most curiously, the results depend on whether I first do the fft and then the ifft or the other way round.
For the test function, I use the Lorentz function 1/(x^2+1). The exact FT is exp(-|t|)*sqrt(pi/2), the IFT yields the same.
1) First FFT and then IFFT: The real part of FFT oscillates, the imaginary part is not zero, and the magnitudes do not match. All this should not be, but the IFFT reproduces the original function just fine.
Hi all, My machine: Mac dual G5, OSX 10.5.4, Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53), numpy 1.1.1 After considerable agony, I succeeded in building and installing scipy from SVN, only to be told upon importing it: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/scipy/__init__.py", line 86, in <module> from numpy.testing import Tester ImportError: cannot import name Tester A message here from Alan McIntyre on June 20, said, in part: "NoseTester will still be made available as numpy.testing.Tester." It appears that each of the seemingly innumerable __init__.py files throughout the scipy sources calls for numpy.testing.Tester. Should I ask over on the scipy list as well? Is there some trivial change that will fake out either numpy or scipy into thinking all is well? Thanks. Bob Pyle
On Wed, Aug 6, 2008 at 3:57 PM, Robert Pyle <rpyle@post.harvard.edu> wrote:
My machine: Mac dual G5, OSX 10.5.4, Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53), numpy 1.1.1
After considerable agony, I succeeded in building and installing scipy from SVN, only to be told upon importing it:
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/scipy/__init__.py", line 86, in <module> from numpy.testing import Tester ImportError: cannot import name Tester
A message here from Alan McIntyre on June 20, said, in part: "NoseTester will still be made available as numpy.testing.Tester."
It appears that each of the seemingly innumerable __init__.py files throughout the scipy sources calls for numpy.testing.Tester.
Should I ask over on the scipy list as well? Is there some trivial change that will fake out either numpy or scipy into thinking all is well?
You will actually need to use NumPy from svn as well, since 1.1.1 didn't have NoseTester (SciPy 0.7 will require NumPy 1.2).
On Aug 6, 2008, at 4:17 PM, Alan McIntyre wrote:
You will actually need to use NumPy from svn as well, since 1.1.1 didn't have NoseTester (SciPy 0.7 will require NumPy 1.2).
Thanks. I can now import scipy, but I'm puzzled by the following: Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import numpy as np np.__version__ '1.2.0.dev5616' import np.testing.Tester Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named np.testing.Tester import scipy scipy.__version__ '0.7.0.dev4603'
How come 'import np.testing.Tester' fails, but scipy imports okay even though it used to fail with a complaint about the absence of np.testing.Tester? Bob
Tester is a class, not a module. Try "from numpy.testing import Tester". On 2008-08-06, Robert Pyle <rpyle@post.harvard.edu> wrote:
On Aug 6, 2008, at 4:17 PM, Alan McIntyre wrote:
You will actually need to use NumPy from svn as well, since 1.1.1 didn't have NoseTester (SciPy 0.7 will require NumPy 1.2).
Thanks. I can now import scipy, but I'm puzzled by the following:
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Type "help", "copyright", "credits" or "license" for more information.
import numpy as np np.__version__ '1.2.0.dev5616' import np.testing.Tester Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named np.testing.Tester import scipy scipy.__version__ '0.7.0.dev4603'
How come 'import np.testing.Tester' fails, but scipy imports okay even though it used to fail with a complaint about the absence of np.testing.Tester?
Bob
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
-- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
participants (5)
-
Alan McIntyre -
Felix Richter -
Robert Pyle -
robert.kern＠gmail.com -
Stéfan van der Walt