Feature request: overloadable updating operators

[bsxfan]

As far as I can see, += and the other updating operators are not handled via overloadable methods. For example, A += B results in A = +(A,B). There is considerable scope for performance gains, especially for matrices, if one could tailor the behaviour of +=. As an example, consider the case of A += B, where both are 1000 by 1000 matrices. I get (total elapsed time for 100 such operations) on an 8-core machine:

1. Standard Julia A+=B: 1s
2. A hand-coded loop that iterates over all 10^6 elements: 0.5s
3. Linalg.BLAS.axpy!(1.0,A,B): 0.02s

(The advantage of 2 over 1 is that it does not have to allocate a temporary matrix to accomodate the sum. The advantage of 3 over 2 is multiple threads and whatever other magic BLAS does.)

[bsxfan]

In the mean time, (similar in spirit to A[diagonal] as discussed in #3164), I have rigged my setindex! so that A[:+] = B calls into BLAS.axpy!. I have a more complicated version also, where A[:+] = B,C,D sums all of A,B,C,D in-place in A.

[IainNZ]

I've always thought not having this was an oversight, but when I asked someone about it, apparently it didn't play nice with type inference? Not sure. But if it is indeed not possible, would be good to document why.

[JeffBezanson]

Nope, it's totally possible and would have no effect on type inference. What we didn't like about it is that it has to work on both mutable and immutable types (e.g. both arrays and numbers). The expression x += y would become a bit of a trap, as it would work fine for numbers, but if the same code were called on arrays it would mutate x unexpectedly. It also creates the possibility of + and += doing totally different things, or accidentally having slightly different behavior.

[IainNZ]

Ah I see, that does make sense. Just enough rope to hang oneself...

[JeffBezanson]

I feel this is addressed by issues #249 #1115 #3022