[SciPy-dev] Single precision FFT

Charles R Harris charlesr.harris@gmail....
Thu Jan 8 13:09:50 CST 2009


On Thu, Jan 8, 2009 at 1:53 AM, David Cournapeau <
david@ar.media.kyoto-u.ac.jp> wrote:

> Anne Archibald wrote:
> >
> > Make sure they're adequately boring.
> >
>
> Note that I did not say they were boring, but shamefully, my Japanese is
> sill poor enough such as formal presentations mostly elude me :)
>
> I fixed fft such as the complex transform handles complex numbers with 0
> imaginary output - effectively making fft of float32 array work in
> single precision. I also discovered at the same time that fftpack has
> some cosine and sine transforms, which is great - I will be able to
> implement some missing functions compared to the matlab signal toolbox
> easily with this.
>
> I discovered something weird - though unrelated: real fft (rfft) in
> numpy and scipy are different in their output format (numpy puts only
> one 'side' of the hermitian output - scipy put all the number in an
> array of reals, which is a bit strange). I don't think the scipy format
> makes much sense ? In C, I can see the advantage of having input/output
> of the same type/size, but in python, I am not sure. Modifying this
> would be a major breakage, though,
>

There was a lot of discussion about this several years back. The "natural"
way for the real transform to store the results of an in place transform is
with the DC and Nyquist frequencies, which are both reals, stored as the
real and imaginary parts of the DC value. This keeps the input and output
arrays the same size but it is somewhat unnatural from the users point of
view. The values may also be shuffled so that the results appear in real,
complex, ... , complex, real order. I forget which way fftpack does it. I
prefer the numpy way for higher level usage, especially as it works better
with ndarrays. Now that fftpack is the only fft version in scipy and there
is only one version of the real transform to deal with it might be a good
time to revisit the question and settle things before we hit version 1.0.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/scipy-dev/attachments/20090108/b0e639a3/attachment.html 


More information about the Scipy-dev mailing list