[SciPy-dev] Fixing correlate: handling api breakage ?

josef.pktd@gmai... josef.pktd@gmai...
Sun May 24 06:28:27 CDT 2009


On Sun, May 24, 2009 at 6:16 AM, David Cournapeau
<david@ar.media.kyoto-u.ac.jp> wrote:
> Hi,
>
>    I have taken a look at the correlate function in scipy.signal. There
> are several problems with it. First, it is wrong on several accounts:
>       - It assumes that the correlation of complex numbers corresponds
> to complex multiplication, but this is not the definition followed by
> most textbooks, at least as far as signal processing is concerned.
>       - More significantly, it is wrong with respect to the ordering:
> it assumes that correlate(a, b) == correlate(b, a), which is not true in
> general.

I don't see this in the results. There was recently the report on the
mailing list that np.correlate
and signal.correlate switch arrays if the second array is longer.

>>> signal.correlate([1, 2, 0, 0, 0], [0, 0, 1, 0, 0])
array([0, 0, 1, 2, 0, 0, 0, 0, 0])
>>> signal.correlate([0, 0, 1, 0, 0],[1, 2, 0, 0, 0] )
array([0, 0, 0, 0, 0, 2, 1, 0, 0])

>
> It may be argued that the first problem is a matter of definition, but I
> don't think the 2nd one is. I would expect some people depending on the
> functionality, though. What should we do ? Adding a new function which
> implements the usual definition, replacing the current one or something
> else ?
>

I found it a bit confusing, that every package needs it's own correlate function
numpy, signal, ndimage, stsci.

Maybe, before adding additional versions of correlate, maybe it is
worth checking how much  overlap and differences there are. I never
tried them with complex numbers, but for floats there is a lot of
duplication (at least from the outside).

Josef


More information about the Scipy-dev mailing list