numpy-discussion

[Numpy-discussion] (a and b) != (b and a) ?

[Geza G. <gr...@nu...>]

Using Numeric-21.0.win32-py2.2 I found this:

Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from Numeric import *
>>> a =3D array((1, 1), 'b')
>>> b =3D array((1, 0), 'b')
>>> a and b
array([1, 0],'b')
>>> b and a
array([1, 1],'b')
>>>

It looks like a bug, or at least very weird. a&b and b&a work correctly.

--
G=E9za Groma
Institute of Biophysics,
Biological Research Center of Hungarian Academy of Sciences
Temesv=E1ri krt.62.
6726 Szeged
Hungary
phone: +36 62 432 232
fax:   +36 62 433 133

Re: [Numpy-discussion] (a and b) != (b and a) ?

[<co...@ph...>]

At some point, Geza Groma <gr...@nu...> wrote:

> Using Numeric-21.0.win32-py2.2 I found this:
>
> Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> from Numeric import *
>>>> a = array((1, 1), 'b')
>>>> b = array((1, 0), 'b')
>>>> a and b
> array([1, 0],'b')
>>>> b and a
> array([1, 1],'b')
>>>>
>
> It looks like a bug, or at least very weird. a&b and b&a work correctly.

Nope. From the Python language reference (5.10 Boolean operations):

The expression x and y first evaluates x; if x is false, its value is
returned; otherwise, y is evaluated and the resulting value is
returned.

Since in your case both a and b are true (they aren't zero-length
sequences, etc.), the last value will be returned.

It works for other types too, of course:

Python 2.1.3 (#1, May 23 2002, 09:00:41) 
[GCC 3.1 (Debian)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> a = 'This is a'
>>> b = 'This is b'
>>> a and b
'This is b'
>>> b and a
'This is a'
>>> 

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|co...@mc...

Re: [Numpy-discussion] (a and b) != (b and a) ?

[Reggie D. <re...@me...>]

This is not, in fact, a bug although I've fallen prey to the same
mistake myself.  I'm assuming what you really wanted was to use
logical_and:

Python 2.2.1 (#1, Apr 29 2002, 15:21:53)=20
[GCC 3.0.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from Numeric import *
>>> a =3D array((1,1), 'b')
>>> b =3D array((1,0), 'b')
>>> logical_and(a,b)
array([1, 0],'b')
>>> logical_and(b,a)
array([1, 0],'b')
>>>=20

From the python documentation:

"The expression x and y first evaluates x; if x is false, its value is
returned; otherwise, y is evaluated and the resulting value is
returned."

So the "and" is just returning its second argument, since both arguments
are considered "True" (containing at least 1 "True" element).

On Tue, 2002-06-11 at 23:27, Geza Groma wrote:
> Using Numeric-21.0.win32-py2.2 I found this:
>=20
> Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from Numeric import *
> >>> a =3D array((1, 1), 'b')
> >>> b =3D array((1, 0), 'b')
> >>> a and b
> array([1, 0],'b')
> >>> b and a
> array([1, 1],'b')
> >>>
>=20
> It looks like a bug, or at least very weird. a&b and b&a work correctly.
>=20
> --
> G=E9za Groma
> Institute of Biophysics,
> Biological Research Center of Hungarian Academy of Sciences
> Temesv=E1ri krt.62.
> 6726 Szeged
> Hungary
> phone: +36 62 432 232
> fax:   +36 62 433 133
>=20
>=20
>=20
> _______________________________________________________________
>=20
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion

Reggie Dugard
Merfin, LLC

Re: [Numpy-discussion] (a and b) != (b and a) ?

[Chris B. <Chr...@no...>]

Reggie Dugard wrote:
> This is not, in fact, a bug although I've fallen prey to the same
> mistake myself.  I'm assuming what you really wanted was to use
> logical_and:

> So the "and" is just returning its second argument, since both arguments
> are considered "True" (containing at least 1 "True" element).

I imagine there is a compelling reason that "and" and "or" have not been
overridden like the comparison operators, but it sure would be nice!

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Numpy-discussion] (a and b) != (b and a) ?

[Tim H. <tim...@ie...>]

From: "Chris Barker" <Chr...@no...>

> I imagine there is a compelling reason that "and" and "or" have not been
> overridden like the comparison operators, but it sure would be nice!

Because it's not possible?

"and" and "or" operate on the basis of the truth of their arguments, so the
only way you can affect them is to overide __nonzero__. Since this is a
unary operation, there is no way to get the equivalent of logical_and out of
it.

In practice I haven't found this to be much of a problem. Nearly every time
I need to and two arrays together, "&" works just as well as logical_and. I
can certainly imagin ecases where this isn't true, I just haven't run into
them in practice.

-tim

Re: [Numpy-discussion] (a and b) != (b and a) ?

[Chris B. <Chr...@no...>]

Tim Hochberg wrote:
> > I imagine there is a compelling reason that "and" and "or" have not been
> > overridden like the comparison operators, but it sure would be nice!
> 
> Because it's not possible?

Well, yes, but it wasn't possible with <,>,== and friends untill rich
comparisons were added in Python 2.1. So I am still wondering why the
same extension wasn't made to "and" and "or". In fact, given that Guido
is adding a bool type, this may be a time to re-visit the question,
unless there really is a compelling reason not to, which is quite
likely. 

> In practice I haven't found this to be much of a problem. Nearly every time
> I need to and two arrays together, "&" works just as well as logical_and.

This has always worked for me, as well, so maybe the answer is that
there is no compelling reason to make a change.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Numpy-discussion] (a and b) != (b and a) ?

[Scott G. <xs...@ya...>]

--- Chris Barker <Chr...@no...> wrote:
> 
> Well, yes, but it wasn't possible with <,>,== and friends untill rich
> comparisons were added in Python 2.1. So I am still wondering why the
> same extension wasn't made to "and" and "or". In fact, given that Guido
> is adding a bool type, this may be a time to re-visit the question,
> unless there really is a compelling reason not to, which is quite
> likely. 
> 

The "and" and "or" operators do short circuit evaluation.  So in addition
to acting like boolean operations, they are also control flow.  For "and",
the second expression is not evaluated if the first one is false.  For
"or", the second expression is not evaluated if the first one is true.  

I'm not clever enough to figure out how an overloaded and/or operator could
implement control flow for the outer expressions.  The outer expressions
"self" and "other" would already be evaluated by the time your
__operator__(self, other) function was called.

C++ has overloadable && and || operators, but overloading them is frowned
on by many.  C++ has the advantage over Python in that it knows the actual
types at compile time.




__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Re: [Numpy-discussion] (a and b) != (b and a) ?

[Andrew P. L. <bs...@ma...>]

On Wed, 12 Jun 2002, Scott Gilbert wrote:
> C++ has overloadable && and || operators, but overloading them is frowned
> on by many.  C++ has the advantage over Python in that it knows the actual
> types at compile time.

Actually, overloading && and || isn't just frowned upon in C++, it's
effectively banned.  The reason is that it replaces short-circuit
semantics with function call semantics and screws up the standard idioms
(if ((a != NULL) && (*a == "a")) { ... } ).  See "Effective C++" by Scott
Meyers.  As far as I know, *none* of the C++ literati hold the opposing
view.

-a