[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