On Sun, May 31, 2009 at 7:18 PM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Charles R Harris wrote:
>
>
> On Sun, May 31, 2009 at 11:54 AM, rob steed <rjsteed@talk21.com
> <mailto:rjsteed@talk21.com>> wrote:
>
>
>     Hi,
>     After my previous email, I have opened a ticket #1117 (correlate
>     not order dependent)
>
>     I have found that the correlate function is defined in
>     multiarraymodule.c and
>     that inputs are being swapped using the following code
>
>        n1 = ap1->dimensions[0];
>        n2 = ap2->dimensions[0];
>        if (n1 < n2) {
>            ret = ap1;
>            ap1 = ap2;
>            ap2 = ret;
>            ret = NULL;
>            i = n1;
>            n1 = n2;
>            n2 = i;
>        }
>
>     I do not know the code well enough to see whether this could just
>     be removed (I don't know c either).
>     Maybe the algorithmn requires the inputs to be length ordered? I
>     will try to work it out.
>
>
> If the correlation algorithm doesn't use an fft and is done
> explicitly, then the maximum overlap for any shift is the length of
> the shortest input.  Swapping the arrays makes that logic easier to
> implement, but it isn't necessary.

But this logic is also wrong if the swapping is not taken into account -
as the OP mentioned, correlate(a, b) is not equal to correlate(b, a) in
the general case. The output is reversed in the second case compared to
the first case.

I didn't say it was *correctly* implemented ;)

Chuck