[Numpy-discussion] Problem with correlate

[Charles R Harris]

On Sun, May 31, 2009 at 9:08 PM, David Cournapeau <
david at ar.media.kyoto-u.ac.jp> wrote:

> Charles R Harris wrote:
> >
> >
> > On Sun, May 31, 2009 at 7:18 PM, David Cournapeau
> > <david at ar.media.kyoto-u.ac.jp <mailto:david at ar.media.kyoto-u.ac.jp>>
> > wrote:
> >
> >     Charles R Harris wrote:
> >     >
> >     >
> >     > On Sun, May 31, 2009 at 11:54 AM, rob steed <rjsteed at talk21.com
> >     <mailto:rjsteed at talk21.com>
> >     > <mailto:rjsteed at talk21.com <mailto:rjsteed at 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 ;)
>
> :) So I gave it a shot
>
> http://github.com/cournape/numpy/commits/fix_correlate
>
> (It took me a while to realize that PyArray_ISFLEXIBLE returns false for
> array object. Is this expected ? The documentation concerning copyswap
> says that it is necessary for flexible arrays, but I think it is
> necessary  for object arrays as well).
>

Don't know. PyArray_ISFLEXIBLE looks like a macro...

#define PyArray_ISFLEXIBLE(obj) PyTypeNum_ISFLEXIBLE(PyArray_TYPE(obj))

#define PyTypeNum_ISFLEXIBLE(type) (((type) >=NPY_STRING) &&  \
                                    ((type) <=NPY_VOID))

And the typecodes are '?bhilqpBHILQPfdgFDGSUVO'. So 'SUV' are flexible and O
is not. I'm not clear on how correlate should apply to any of 'SUV' but it
might be worth having it work for objects.


> It still bothers me that correlate does not conjugate the second
> argument for complex arrays...
>

It bothers me also... Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20090531/e58e73bf/attachment.html>