On 29/08/2007, Charles R Harris <charlesr.harris@gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fftfix
Type: application/octet-stream
Size: 1241 bytes
Desc: not available
Url : http://projects.scipy.org/pipermail/numpy-discussion/attachments/20070829/dafce1e6/attachment.obj