[Numpy-discussion] Bug fix or behavior change?

[Charles R Harris]

On Sat, Sep 27, 2008 at 12:51 AM, Travis E. Oliphant <oliphant at enthought.com
> wrote:

> Charles R Harris wrote:
> > Hi All,
> >
> > Currently subtract for boolean arrays is defined in
> >
> > /**begin repeat
> >  * Arithmetic operators
> >  *
> >  * # OP = ||, ^, &&#
> >  * #kind = add, subtract, multiply#
> >  */
> > static void
> > BOOL_ at kind@(char **args, intp *dimensions, intp *steps, void *func)
> > {
> >     register intp i;
> >     intp is1=steps[0],is2=steps[1],os=steps[2], n=dimensions[0];
> >     char *i1=args[0], *i2=args[1], *op=args[2];
> >     for(i=0; i<n; i++, i1+=is1, i2+=is2, op+=os) {
> >         *((Bool *)op)=*((Bool *)i1) @OP@ *((Bool *)i2);
> >     }
> > }
> > /**end repeat**/
> >
> >
> > Note that this might yield unexpected results if the boolean value is
> > not 0 or 1, which is possible using views. Note also that bitwise_xor
> > converts the boolean to 0 or 1 before using ^. I think subtract should
> > work the same way, but that would change current behavior. So... do I
> > make the change and call it a bug fix or leave it as it is?
>
> I think it's a bugfix and so am +1 on the change.
>

Done. I've made all the boolean ufuncs convert args to  0 or 1 before
applying the operators. Next question, what about logical_and applied to
complex numbers. Currently it gives

In [16]: a = complex(1,0)

In [17]: b = complex(0,1)

In [18]: logical_and(a,b)
Out[18]: False

i.e., it && all the components together. I suspect what it should be doing
is anding first and second arguments being non-zero.

Also, there is this bit for absolute of signed numbers

static void
@TYPE at _absolute(char **args, intp *dimensions, intp *steps, void *func)
{
    UNARY_LOOP {
        const @type@ in1 = *((@type@ *)ip1);
        *((@type@ *)op) = (in1 < 0) ? -in1 : in1;
        *((@type@ *)op) += 0; /* clear sign-bit  */
    }
}

I don't understand the clearing the sign-bit line, it looks unnecessary. Was
there some problem that this once fixed?

Also, the signature for the ones_like ufuncs has 1 input argument, but only
the output argument is used. I suppose changing this would be a pain, but
it's a bit odd.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080927/97ea0eaf/attachment.html>