Numeric:FFT inverse_real_fft doesn't trevni!

[Michael Huster]

>From: Christian Tismer <tismer at appliedbiometrics.com>
>To: mhuster at hotmail.com
>CC: python-list at cwi.nl
> > mhuster at hotmail.com wrote:
> >
> > The FFT module with the LLNL Numeric stuff does not seem to perform an
> > inverse on the result of real_fft. (At least not in an intuitive
> > manner.) An N point real_fft returns N/2 +1 complex numbers. From
> > experience, not documentation, I guess that element 0 is real and the DC
> > component, and element N/2 is real and the Nyquist value.
> >
> > But, trying inverse_real_fft does not seem to give the number of values
> > or the values I expect. I thought that calling inverse_real_fft on the
> > same array as real_fft produced would give back the original array,
> > possibly scaled by N. Not so. I pasted in a sample of a session.
>
>Christian Tismer replied:
>No, that's a misconception.
>The real fft is just a speedup for cases where your data
>has only real coefficients.
Correct. An N point real series into real_fft returns N/2+1 coefficients. 
But the first (DC) and last (Nyquist) are purely real, thus the number of 
independent coefficients are the same. The complex coefficients are the 
positive frequencies *ONLY*.

There IS an algorithm for the inverse with the same speedup.

>Providing an inverse function
>would be useless, since after any modifications of your
>complex result, you will usually not expect a real result.
Not, true. Since the returned coeficients are only the positive frequencies, 
I should be able to do operations such as bandpass, correlate, etc just on 
these coefficients then call a *proper* inverse_real_fft and get back a 
purely real timeseries.

This is the way we have implemented it in C using FFTPACK. FFTPACK has such 
a routine which will take the results of real_fft, and invert them. The 
wrapped FFTPACK routine in the FFT module just is not the one I've used in 
the past. There is the SAME efficiency on the inverse as there is on the 
forward. We had separate, wrapped calls to set up the work arrays, ezffti_, 
then a wrapped call to the do the real forward fft, ezfftf_, and finally a 
wrapped call to ezfftb_ for the inverse. With the wrapping we got the 
efficiency of the real fft both ways, and the inverse of the forward fft 
equals (within numerical error) the original timeseries.

>The inverse_real_fft is just a reverse FFT on real data,
>likewise assuming that you are in the frequency domain
>with real data.
It does not make sense to have purely real frequency domain data. Inverse 
transforming a purely real frequency domain data results in a minimum time 
waveform. E.g. a filtered delta function. The analogy between a purely real 
TIME series (like a pressure) does not go over into purely real frequency 
domain series.

>(sounds strange? Exactly as strange as for the time domain,
>that's what causes all the Nyquist trouble :-)
Different issue.


_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com