logical_and operator, &&, is missing?
It seems that the logical operators || and &&, corresponding to logical_or and logical_and are missing; one can do z = logical_and(x,y) but not z = x && y Is there an inherent reason, or is this a bug? z = (x == y) works, and a comment in umathmodule.c.src suggests that && and || should also: /**begin repeat #kind=greater, greater_equal, less, less_equal, equal, not_equal, logical_and, logical_or, bitwise_and, bitwise_or, bitwise_xor# #OP=>, >=, <, <=, ==, !=, &&, ||, &, |, ^# **/ My version is '0.9.9.2584'. Eric
Eric Firing wrote:
It seems that the logical operators || and &&, corresponding to logical_or and logical_and are missing; one can do
z = logical_and(x,y)
but not
z = x && y
Is there an inherent reason, or is this a bug?
Python does not have a && operator. It has an "and" keyword, but that cannot be overridden. If you know x and y to be boolean arrays, & and | work fine.
z = (x == y)
works, and a comment in umathmodule.c.src suggests that && and || should also:
/**begin repeat
#kind=greater, greater_equal, less, less_equal, equal, not_equal, logical_and, logical_or, bitwise_and, bitwise_or, bitwise_xor# #OP=>, >=, <, <=, ==, !=, &&, ||, &, |, ^# **/
Those operators are the C versions that will be put in the appropriate places in the generated code. That is not a comment for documentation. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Robert Kern wrote:
Eric Firing wrote:
It seems that the logical operators || and &&, corresponding to logical_or and logical_and are missing; one can do
z = logical_and(x,y)
but not
z = x && y
Is there an inherent reason, or is this a bug?
Python does not have a && operator. It has an "and" keyword, but that cannot be overridden. If you know x and y to be boolean arrays, & and | work fine.
Out of curiosity, is there a simple explanation as to why "and" cannot be overridden but operators like "&" can? Is it a fundamental distinction between operators and keywords? In any case, it sounds like we are indeed stuck with an unfortunate wart on numpy, unless some changes in Python can be made. Maybe for Python3000... The NumPy for Matlab users wiki is misleading in this area; I will try to fix it. Eric
Eric Firing wrote:
Robert Kern wrote:
Eric Firing wrote:
It seems that the logical operators || and &&, corresponding to logical_or and logical_and are missing; one can do
z = logical_and(x,y)
but not
z = x && y
Is there an inherent reason, or is this a bug?
Python does not have a && operator. It has an "and" keyword, but that cannot be overridden. If you know x and y to be boolean arrays, & and | work fine.
Out of curiosity, is there a simple explanation as to why "and" cannot be overridden but operators like "&" can? Is it a fundamental distinction between operators and keywords?
Sort of. "and" and "or" short-circuit, that is they stop evaluating as soon as the right value to return is unambiguous. In [1]: def f(): ...: print "Shouldn't be here." ...: ...: In [2]: False and f() Out[2]: False In [3]: True or f() Out[3]: True Consequently, they must yield True and False only.
In any case, it sounds like we are indeed stuck with an unfortunate wart on numpy, unless some changes in Python can be made. Maybe for Python3000...
The NumPy for Matlab users wiki is misleading in this area; I will try to fix it.
Thank you. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Robert Kern wrote:
Eric Firing wrote:
Robert Kern wrote:
Eric Firing wrote:
It seems that the logical operators || and &&, corresponding to logical_or and logical_and are missing; one can do
z = logical_and(x,y)
but not
z = x && y
Is there an inherent reason, or is this a bug?
Python does not have a && operator. It has an "and" keyword, but that cannot be overridden. If you know x and y to be boolean arrays, & and | work fine.
Out of curiosity, is there a simple explanation as to why "and" cannot be overridden but operators like "&" can? Is it a fundamental distinction between operators and keywords?
Sort of. "and" and "or" short-circuit, that is they stop evaluating as soon as the right value to return is unambiguous.
In [1]: def f(): ...: print "Shouldn't be here." ...: ...:
In [2]: False and f() Out[2]: False
In [3]: True or f() Out[3]: True
Consequently, they must yield True and False only.
That makes sense, and implies that the real solution would be the introduction of operators && and || into Python, or a facility that would allow extensions to add operators. I guess it would be a matter of having hooks into the parser. I have no idea whether either of these is a reasonable goal--but it certainly would be a big plus for Numpy. Eric
Eric Firing wrote:
That makes sense, and implies that the real solution would be the introduction of operators && and || into Python, or a facility that would allow extensions to add operators. I guess it would be a matter of having hooks into the parser. I have no idea whether either of these is a reasonable goal--but it certainly would be a big plus for Numpy.
I don't really see how. We already have the & and | operators. The only difference between them and the && and || operators would be that the latter would automatically coerce to boolean arrays. But you can do that explicitly, now. a.astype(bool) | b.astype(bool) Of course, it's highly likely that you are applying & and | to arrays that are already boolean. Consequently, I don't see a real need for more operators. But if you'd like to play around with the grammar: http://www.fiber-space.de/EasyExtend/doc/EE.html -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Robert Kern wrote:
Eric Firing wrote:
That makes sense, and implies that the real solution would be the introduction of operators && and || into Python, or a facility that would allow extensions to add operators. I guess it would be a matter of having hooks into the parser. I have no idea whether either of these is a reasonable goal--but it certainly would be a big plus for Numpy.
I don't really see how. We already have the & and | operators. The only difference between them and the && and || operators would be that the latter would automatically coerce to boolean arrays. But you can do that explicitly, now.
a.astype(bool) | b.astype(bool)
Another difference pointed out in the Wiki is precedence, which requires one to be more careful about parentheses when using the bitwise operators. This arises because although the bitwise operators effectively do the right thing, given boolean arguments, there really is a difference between & and &&--that is why C, for example, has both. Using & when one means && is a hack that obscures the meaning of the code, and using logical_and is clear but cluttered--a significant step away from the goal of having code be clear, concise and readable. I suspect that many other people will trip over the lack of && in the same way that I have, and will similarly consider it an irritant that we work around because we have to, not because it is good.
Of course, it's highly likely that you are applying & and | to arrays that are already boolean. Consequently, I don't see a real need for more operators.
But if you'd like to play around with the grammar:
Interesting, thanks--but I will back off now. Eric
On Sat, 24 Jun 2006, Eric Firing apparently wrote:
I suspect that many other people will trip over the lack of && in the same way that I have, and will similarly consider it an irritant that we work around because we have to, not because it is good.
I agree with this. In addition, turning to & when && is wanted will likely cause occasional stumbles over operator precedence. (At least I've been bitten that way.) But I do not see this changing unless Python grants the ability to define new operators, in which case I'm sure the wish lists will come out ... Cheers, Alan Isaac
On 6/24/06, Eric Firing <efiring@hawaii.edu> wrote:
Out of curiosity, is there a simple explanation as to why "and" cannot be overridden but operators like "&" can? Is it a fundamental distinction between operators and keywords?
There is no fundamental reason. In fact overloadable boolean operators were proposed for python: <http://www.python.org/dev/peps/pep-0335>
participants (4)
-
Alan G Isaac -
Eric Firing -
Robert Kern -
Sasha