BitArray surprise

[Gabor]

I am getting acquainted with BitArrays;  but here is a surprise:

julia> [1:3].<2
3-element BitArray:
  true
  false
  false

julia> [1:3].<3
3-element BitArray:
  true
  true
  false

 Now let's combine them:

julia> ([1:3].<2) | ([1:3].<3)
3-element BitArray:
  true
  true
  false

Correct. But without parentheses:
  

julia> [1:3].<2 | [1:3].<3
3-element BitArray:
  false
  false
  false

What is going on here ?
Is it a wrong expectation that .< is of higher precedence than | ?

[Harlan Harris]

Yes, the precedence is the other way around. The canonical operator precedence list is at the top of src/julia-parser.scm, with higher-precendence at the bottom. The | operator has the same precedence as operators like + and -, higher than the comparison operators like == and .<. I believe this is the case in most programming languages.

--
 
 
 

[Gabor]

Thank you for the explanation Harlan!

 

I must accept this, but considering the operator precedence of numbers

( e.g. 3<2*2 && 10>3^2)  it still feels counterintuitive.

An operator precedence table in the documentation would be useful.

[Stefan Karpinski]

Note that && and || are different than | and & and have different precedence. We should add an operator precedence table to the manual.

--
 
 
 

[Gabor]

I readily admit that I do not see the big picture.

All I need are chained arithmetic and boolean comparisons of arrays

with the simplest possible operators and the minimum number of extra parentheses.

 

e.g: 

find( v>h1 & v<=h2 & code!=0 & A>0.05*max(A)

 

It seems that for this purpose the only way to go are BitArrays,

operators  like .<, .<=, .==  instead of <, <=, == even for scalars

and a few extra parentheses.

 

e.g: 

find( (v.>h1) & (v.<=h2) & (code.!=0) & (A.>0.05*max(A)) )

 

This is surely manageable but feels a little clumsy.