Operator precedence of & and | is surprising as element-wise boolean operators

[mbauman]

I just got bit by the python-like operator precedence for the operators | and &. As bitor and bitand, it's a wonderful choice (making checking for bit flags much simpler — a common gotcha in C).

But when behaving as their element-wise boolean counterparts to || and &&, it is surprising. A < 1 || A > 2 must be written differently if A is an array: (A .< 1) | (A .> 2). Perhaps all that's needed here is a bit more documentation (i.e., putting https://github.com/JuliaLang/julia/blob/master/src/julia-parser.scm#L1-L19 into the Mathematical Operators page, or as something to mention to users coming from Matlab).

But as I look at the source for |(::StridedArray,::StridedArray), I see that it's actually applying the bitwise operator to all elements. As a radical alternative, what about adding .&& and .|| with similar precedence to && and || that ensures boolean elements? Functionally, & and .&& would behave the same on logical arrays, but they'd each have the precedence one would expect in each context. (Of course, there'd still be some cognitive dissonance here as the elementwise boolean operators couldn't short-circuit like their scalar equivalents).

[JeffBezanson]

There might not be a single precedence ordering perfect for all cases. The main problem here is that the result of < is seldom combined with anything; i.e. (x<1) + 2 is quite rare, so without explicit parens parses as x<(1 + 2).

[StefanKarpinski]

I kind of suspect that our precedences could use a little tweaking, but yeah, every choice is bad in some way.

[mbauman]

Yes, exactly. I definitely think the precedence for bitand is the right choice. That's what led to my brainstorm of the .&& operators.

Perhaps it's just my Matlab-think that causes this confusion, where & truly is the element-wise little brother to scalar &&.

[malmaud]

+1 for .&& and .||. It seems totally consistent with .*, etc. My understanding is Numpy only ended up using & for element-wise "logical and" since they ran out of infix operators. It's a constant source of confusion (eg, from http://wiki.scipy.org/NumPy_for_Matlab_Users,

"Precedence: Numpy's & operator is higher precedence than logical operators like < and >; Matlab's is the reverse.
If you know you have boolean arguments, you can get away with using Numpy's bitwise operators, but be careful with parentheses, like this: z = (x > 1) & (x < 2). The absence of Numpy operator forms of logical_and and logical_or is an unfortunate consequence of Python's design".)

Also this is anecdotal, but I suspect taking the element-wise "logical and" of boolean vectors is a more common operation than bitwise operations and so if & is going to maintain its current meaning, it might be worth tweaking the precedence to be the same as .*.

[nalimilan]

I must admit that the fact that the priority order differs between |/.== and ||/== reminds me a little of the R Inferno -- something you absolutely want to avoid. Every choice is bad in some way, but inconsistent solutions are bad in all ways! ;-)

Using the same operators for so different things as bitwise and boolean operations is not ideal. Does any other language use that pattern? In Matlab and R & only does the latter, and in Numpy it only does the former.

Adding .&& and .|| might be a good and consistent solution. In that case & and | would better be eventually reserved to bitwise operations (do not offer two slightly different ways of doing the same thing).

[JeffBezanson]

What is the difference between bitwise and boolean?

The difference between & and && is that && is a control flow operator; it short-circuits. So .&& doesn't really make much sense.

[StefanKarpinski]

Yeah, .&& and .|| don't make any sense. I almost regret using | and & for bitwise or and and. Those are pretty uncommon operations and are arguably clearer if you have to write them in function notation – e.g. there are no precedence issues that way. Then we could have used | for piping without punning.

[malmaud]

Those are fair points. Maybe something like .&? It would be consistent with most binary operators having a '.' version that is element-wise, and could have the expected precedence (later than .<).

[nalimilan]

@JeffBezanson IIUC, & and | have a higher priority than && and || because it's more practical for common patterns of bitwise operations. That's why having a separate element-wise boolean operator would make sense, to provide a consistent precedence order for scalar and element-wise comparison operators.

The whole thing is quite confusing because of the multiple meanings of operators...

julia> help("&&")
Base.&&(x, y)

   Boolean and

So && is not only defined as short-circuit: it also intuitively means that you expect to work with booleans only. This gives support to the idea of having an element-wise version working only with boolean arrays. One could also have & work only for scalars (and operating bitwise), and .& for arrays.

Honestly, the issue of short-circuit really seems secondary to me; of course, when working element-wise it doesn't make sense to short-circuit. But I see that as a side effect. The fact that Matlab offers the choice between two operators (though & and | do short-circuit in if!) looks like a design mistake: when do you need that? Even C does not offer this choice. The real question is: what's the appropriate precedence of bitwise and boolean operators, and do they need to be separated because of that.

@StefanKarpinski Yeah, I was thinking too that wasting & and | for bitwise operations is not that great; but no language uses different operators. Is the alternative of using functions a good solution? Matlab and R do that, there might be a good reason.

[JeffBezanson]

&& does not have multiple meanings. The short-circuit behavior only makes
sense because of the boolean operation it does; they cannot be separated.

A function like & but accepting only boolean arrays would be silly. The
"boolean" and "bitwise" behaviors are the same; a boolean is 1 bit.
On Dec 22, 2013 12:35 PM, "Milan Bouchet-Valat" notifications@github.com
wrote:

@JeffBezanson https://github.com/JeffBezanson IIUC, & and | have a
higher priority than && and || because it's more practital for common
patterns of bitwise operations. That's why having a separate element-wise
boolean operator would make sense, to provide a consistent precedence order
for scalar and element-wise comparison operators.

The whole thing is quite confusing because of the multiple meanings of
operators...

julia> help("&&")
Base.&&(x, y)

Boolean and

So && is not only defined as short-circuit: it also intuitively means
that you expect to work with booleans only. This gives support to the idea
of having an element-wise version working only with boolean arrays. One
could also have & work only for scalars (and operating bitwise), and .&for arrays.

Honestly, the issue of short-circuit really seems secondary to me; of
course, when working element-wise it doesn't make sense to short-circuit.
But I see that as a side effect. The fact that Matlab offers the choice
between two operators (though & and | do short-circuit in if!) looks like
a design mistake: when do you need that? Even C does not offer this choice.
The real question is: what's the appropriate precedence of bitwise and
boolean operators, and do they need to be separated because of that.

@StefanKarpinski https://github.com/StefanKarpinski Yeah, I was
thinking too that wasting & and | for bitwise operations is not that
great; but no language uses different operators. Is the alternative of
using functions a good solution? Matlab and R do that, there might be a
good reason.

?
Reply to this email directly or view it on GitHubhttps://github.com//issues/5187#issuecomment-31091723
.

[nalimilan]

But what about operator precedence? If they are the same, why don't & and && have the same precedence?

[JeffBezanson]

The thing is, short-circuiting is not secondary, but essential. If it were
not for that, they would be the same operator. Short-circuit also
immediately implies scalar boolean, since it has to make a single decision.

I guess I would consider changing the precedence of &. But the key is to
see && as primarily for control flow; it is not even a function, while & is
a normal generic function.
On Dec 22, 2013 1:09 PM, "Milan Bouchet-Valat" notifications@github.com
wrote:

But what about operator precedence? If they are the same, why don't & and
&& have the same precedence?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/5187#issuecomment-31092386
.

[mbauman]

Regardless of whether the precedence of & changes or a third set of boolean operators is introduced specifically for element-wise boolean arrays, I think it's very important to allow syntax such as B[A .< 1 | A .> 2] without parentheses. In a language like Julia, I think that's a much more common operation than, say, checking bitfields.

[StefanKarpinski]

+1 for what @mbauman said. I would also throw into the mix that Perl and Ruby have and and or operators that have short-circuit behavior like && and || but much lower precedence. I don't recall if that's because && and || have precedence like & and | or not, but it might be. It's quite subjective, of course, but I happen to think that and and or are much more intuitive as control flow primitive because they look like keywords, not operators.