# [Numpy-discussion] logical priority

Mark Histed histed at MIT.EDU
Thu Feb 10 08:44:00 EST 2005

```> Anyway, we've wandered afar from the main point:  what is the best way
> to duplicate the functionality of the following MATLAB snippet:
>
> f = ~isnan(data1) & ~isnan(data2);
> plot(x,data1(f),x,data2(f))

I know this has been talked about before on this list, but only in
bits and pieces.  Can I summarize the way I understand the situation
and hopefully others can correct me?  I use MATLAB and Numeric often;
I have rarely used Numarray.

Summary:

For people moving from Matlab to Numeric/Numarray, the recommendation
is to use Numeric's "&" in place of Matlab's "&" to combine logical
arrays for indexing.  Different behavior results if the inputs have
entries > 1, and you have to put parenthesis around any inputs that
use relational operators.
Also, one should use Numeric's "and" in place of Matlab's "&&".

Details:

In MATLAB (R14SP1) there are three logical "and" operators:

"&": a binary operator which performs element-by-element logical AND.
For its purposes, 0 is FALSE and every other numerical value is TRUE.
"&&": a binary operator which performs logical AND, but does
short-circuiting, and only works with scalar elements (length-1 arrays)
"bitand()" : a function which takes two integers and does bitwise-and
on their binary representations

http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/ch12_n11.html#38948

I think that these map onto the python operators in the following way:
MATLAB      Python/Numeric
------      --------------
&&          and
&           ufunc logical_and()
bitand      &

Some inconsistencies in behavior (between Numeric and Matlab) occur
when one uses Numeric's "&" like MATLAB "&".  I can think of:
* Non-logical {0,1} inputs: Numeric's output is an integer, the
bitwise and of the inputs, Matlab's output is a logical array,
either 1 or 0.
* Precedence: Numeric's "&" operator is higher prec than its relational
operators, MATLAB is the reverse

And an inconsistency between MATLAB's "&&" and Numeric's "and":
* MATLAB returns an error when the arguments to && are not logical
scalars, Numeric returns the second argument as the expression's
value. (but Numarray behaves like MATLAB)

Does that seem right?

Regards,
Mark

----------------------------------------------------------------

Matlab example:

>> a = [0,1,2];
>> b = [1,1,63];
>> a & b
ans =
0     1     1
>> a && b
??? Operands to the || and && operators must be convertible to logical
scalar values.
>> bitand(a,b)
ans =
0     1     2
>> a > 1 & b > 1
ans =
0     0     1
>> (a > 1) & (b > 1)
ans =
0     0     1

----------------------------------------------------------------

Numeric example:

Python 2.3.4 (#2, Sep 24 2004, 08:39:09)
[GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2
>>> import Numeric as N
>>> a = N.array([0,1,2]);
>>> b = N.array([1,1,63]);
>>> N.logical_and(a,b)
array([0, 1, 1])
>>> a & b
array([0, 1, 2])
>>> a and b
array([ 1,  1, 63])
>>> a > 1 & b > 1
array([0, 0, 0])
>>> (a > 1) & (b > 1)
array([0, 0, 1])

----------------------------------------------------------------

Numarray example:
>>> import numarray as na
>>> a = na.array([0,1,2])
>>> b = na.array([1,1,63])
>>> na.logical_and(a,b)
array([0, 1, 1], type=Bool)
>>> a and b
RuntimeError: An array doesn't make sense as a truth value.  Use
sometrue(a) or alltrue(a).
>>> a & b
array([0, 1, 2])
>>>

----------------------------------------------------------------

On Wed, Feb 09, 2005 at 10:11:56AM -0800, Stephen Walton wrote:
> Fernando Perez wrote a good deal clarifying how Python's logical
> operators work, for which I'm grateful.  One brief comment:
>
> >Bytecode analysis can be really useful to understand this kind of
> >subtle issues.  I can't think of any language where this approach is
> >as easy to do and friendly as in python.
>
> Pardon me, but this sounds a bit like looking at the assembly language
> Fortran generates in order to understand the subtleties of that language
> :-) .  I know people who used to do that, and were proud of it, but I'd
> rather the language itself didn't behave in surprising ways.  At least
> in Fortran, 'a .and. b' only made sense if a and b were both of type
> LOGICAL;  in fact, it was a compile time error if they weren't.
>

>
> ?
>
>
>
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.