[Numpy-discussion] chirp-z
David Cournapeau
david at ar.media.kyoto-u.ac.jp
Mon May 28 04:47:24 EDT 2007
Stefan van der Walt wrote:
>
> There is also the problem that you suddenly double your memory usage.
Is it a problem for 1d signals ? I cannot think about an example where
you would need to do fft long enough such as this is a problem for the
applications I know of fft. Also, if you do several 1d fft of the same
size, in most cases I know, you can pack several of them together, and
do "vectorized" fft, which will not take the double of memory.
Now, I know there are many applications where you use fft that I don't
know about, and this may be a problem for multi dimensional problems.
But then, the cost in direct implementation would be really slow (I am
of course talking of cases where you need the full
convolution/correlation; if you need only a part of it, then it is a
totally different matter, and I don't think there is a good way to know
automatically what's best; I had to code my own lpc code for this exact
reason in matlab).
I think the problem of correlation and convolution right now that there
are several implementations of them in different places, which is a bit
confusing a first (at least it was for me when I started using scipy).
If I do a grep on convolution for numpy and scipy sources, I get:
- numpy/core/numeric : implemented using correlation, which itself
uses direct implementation (in C, with dot).
- scipy.stsci and scipy.ndimage: I have never used those packages.
- scipy.fftpack : uses fft, obviously.
- scipy.signal : proposes both with and without fft.
Maybe there would be a way to avoid so many packages to provide more or
less the same functionalities ? To provide a fast, and without too much
memory overhead correlation function was one of the main reason for the
ticket 400 I opened in numpy trac (provide a hook to an fft
implementation at the C level).
cheers,
David
More information about the NumPy-Discussion
mailing list