On 29/08/2007, Charles R Harris <[EMAIL PROTECTED]> wrote: > > > What is going on is that the coefficient at the Nyquist frequency appears > once in the unextended array, but twice when the array is extended with > zeros because of the Hermitean symmetry. That should probably be fixed in > the upsampling code.
Is this also appropriate for the other FFTs? (inverse real, complex, hermitian, what have you) I have written a quick hack (attached) that should do just that rescaling, but I don't know that it's a good idea, as implemented. Really, for a complex IFFT it's extremely peculiar to add the padding where we do (between frequency -1 and frequency zero); it would make more sense to pad at the high frequencies (which are in the middle of the array). Forward FFTs, though, can reasonably be padded at the end, and it doesn't make much sense to rescale the last data point. > The inverse irfft also scales by dividing by the new transform size instead > of the original size, so the result needs to be scaled up for the > interpolation to work. It is easy to go wrong with fft's when the correct > sampling/frequency scales aren't carried with the data. I always do that > myself so that the results are independent of transform size/interpolation > and expressed in some standard units. The scaling of the FFT is a pain everywhere. I always just try it a few times until I get the coefficients right. I sort of like FFTW's convention of never normalizing anything - it means the transforms have nice simple formulas, though unfortunately it also means that ifft(fft(A))!=A. In any case the normalization of numpy's FFTs is not something that can reasonably be changed, even in the special case of the zero-padding inverse (and forward) FFTs. Anne
fftfix
Description: Binary data
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
