[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
Type "help", "copyright", "credits" or "license" for more information.
>>> 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.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
More information about the NumPy-Discussion
mailing list