& does not broadcast, and there is no .& (similar problem for "or")

[tomasaschan]

Given two logical arrays with different dimensions, there seems to be no straightforward way to broadcast and:

a = [1:10] .< 7
b = [1:10]' .> 3
a & b # ERROR: dimensions must match
a .& b # ERROR: syntax: extra token "b" after end of expression
a && b # ERROR: type: non-boolean (BitArray{1}) used in boolean context
a .&& b # ERROR: syntax: invalid identifier name "&&"

See also discussion on the users list. It turns out a .* b achieves the desired effect. For consistency, I suggest adding a dotted version .& that works just like .*. The latter works, but it's a counterintuitive way to express the intention of broadcasting and, and it relies on the fact that booleans happen to be represented by 0 and 1. There also is no corresponding way to express "broadcasting or" without resorting to tricks relying on the underlying representation, so I'd like to suggest adding .| as well. (And/or adding .&& and .||, if that makes more sense.)

[ivarne]

As long as && and || are short circuit operations, the element vize, broadcasting operations would not make much sense.

[tomasaschan]

@ivarne True that. Forget all about .&& and .||.

[carlobaldassi]

On the mailing list, it @toivoh also suggested that bitwise operations (&, |, $) should broadcast by default. I think this makes sense, since they are inherently element-wise and therefore it seems we could avoid introducing new operators. I tried to test if there is a difference in performance introduced by the broadcasting and I couldn't measure any, or perhaps something of the order of 2% at most (I tested a & b vs a .* b with equal-sized a and b: the latter uses the former but puts it in within a try/catch block in order to determine if broadcasting is needed. This apparently doesn't harm performance neither for small not large arrays; my guess is that the time is dominated by allocation. When broadcasting is explicitly asked for instead, the performance degradation is very noticeable, implying that we would still need internal non-broadcasting bitwise BitArray functions for the special case of equal-sized arrays.)

[StefanKarpinski]

I think it is correct that &, | and $ should broadcast since they are inherently element-wise.

[toivoh]

We could make the broadcasting operations first check if broadcasting is
needed and otherwise fall back to plain elementwise operations. This would
probably be a good idea in general as long as there is non-negligible
overhead for broadcasting.

[stevengj]

Note that #17393 added .& and .| as parsed operators (but undefined by default), and #17623 will make them correspond to (fusing) broadcast operations.

However, .$ is not supported yet because of the parsing ambiguity for a.$b (used in macros and interpolated expressions).

[davidavdav]

Working on #18977 I implemented broadcasting .& and .|, but that is not included in that PR. With #18977 .$ is not strictly necessary anymore, it is covered by xor.(), but an equivalent .⊻ is easy. With some rebasing it should be straightforward for me to make a PR for this issue, after #18977 has been merged.

[stevengj]

@davidavdav, every operator will get a broadcasted dot variant in #17623, so I'd prefer that you didn't add more "manual" ones now. (#17623 is on hold for a little while now while the broadcast machinery gets improved for sparse matrices.)

[davidavdav]

Sure, no problem, a generic solution is of course better.

[stevengj]

#17623 gives use .& and .|, so I think this can be closed?