which operators should have n-ary parsing?

[dmbates]

As mentioned in

https://groups.google.com/forum/#!topic/julia-users/CQs8uGvbnIo

having A & B & C generate Expr(:call,:&,:A,:B,:C) instead of Expr(:call,:&,Expr(:call,:&,:A,:B),:C) would be helpful for the formula language in DataFrames.jl

[simonbyrne]

It would also be useful to have n-ary elementwise operations (.+ and .*).

[ViralBShah]

+1 for more n-ary elementwise operators.

[jakebolewski]

We should probably change this behavior in 0.4.

[JeffBezanson]

Actually I was thinking of getting rid of the n-ary + and *. It's a somewhat strange and surprising feature that's not very useful.

[ivarne]

Whether we want to generalize or remove the pattern, 0.4 seems like the version to do it in.

[simonbyrne]

Was there any particular place that it causes problems? I'm willing to concede that its use is not particularly widespread, but it is handy for metaprogramming. Also it might be more useful for arrays once we have a lazy transpose: e.g. we could do u'*A*v without allocating any intermediate arrays.

[JeffBezanson]

True; it's similarly handy for string concatenation, where doing A*B*C*... in a single call is much more efficient (though I'd be just as happy not using * for string cat at all).

We haven't taken advantage of this feature much for arrays, partly because a*b + c is more useful than a + b + c. However the u'*A*v case is pretty compelling.

What would not be good is randomly picking operators to add to this set one by one. What is the general rule?

[jiahao]

To state the obvious, the operator should be associative.

[ivarne]

@jiahao So the non-associativeness of + and * for FloatingPoint makes them excluded by the general rule?

Associative would also a problematic measure if the operands have different types, and promotion/conversion rules makes the resulting type different.

[andreasnoack]

Should a rule like associativity be connected to the operator as such, i.e. "try only to define method for * that are associative".

[simonbyrne]

Yes, any associative operator should be okay. Ones that come to mind:

• concatenation of strings
• * and + (and their broadcasting versions .+ and .*)
• gcd and lcm (we don't have operators for those)
• ∨ (join) and ∧ (meet) on lattices:
• ∪ (union) and ∩ (intersection)
• max and min (and minmax)
• & and | (and && and ||)
• hypot

[simonbyrne]

So the non-associativeness of + and * for FloatingPoint makes them excluded by the general rule?

I think we should define them for operators which can be associative, not ones that are always associative.