x.*x not customizable

[malmaud]

There doesn't seem to be a way to get x.*x to do something different than x*x, as the following perhaps naive example shows:

import Base: *

type T
    t
end

Base.broadcast(::typeof(*), t1::T, t2::T) = 1
*(t1::T, t2::T) = 2
x = T(1)
x*x # Prints 2

x.*x # Also prints 2

If there really isn't a way, this is a non-trivial breaking regression in functionality compared to .5 that some packages depended upon.

[KristofferC]

julia> import Base: *

julia> type T
           t
       end

julia> Base.broadcast(::typeof(*), t1::T, t2::T) = 1

julia> *(t1::T, t2::T) = 2
* (generic function with 182 methods)

julia> T(1)*T(2) # Prints 2
2

julia> T(1).*T(2) # Also prints 2
1

?

[malmaud]

What version are you on?

[KristofferC]

0.6-rc2

[mbauman]

Right, the problem is when you use a repeated symbol:

julia> x = T(1)
T(1)

julia> x .* x
2

Because:

julia> expand(:(T(1).*T(2)))
:((Base.broadcast)(*, T(1), T(2)))

julia> expand(:(x.*x))
:($(Expr(:thunk, CodeInfo(:(begin
        $(Expr(:thunk, CodeInfo(:(begin
… # effectively broadcast(y->y*y, x)

[malmaud]

Ah woops, I wrote my example wrong. I'll edit it.

[andyferris]

Function-based implementations of broadcast seem rather fragile. I think it's only suitable as an optimization to get the same result, and even then it's bad to have users rely upon the optimization...

[oxinabox]

Function-based implementations of broadcast seem rather fragile.

They are rather common.
Eg @SimonDanisch wrt: https://github.com/JuliaGPU/GPUArrays.jl/blob/master/src/abstractarray.jl#L182-L224

cf: FluxML/Flux.jl#31
cf: malmaud/TensorFlow.jl#135

[andyferris]

Yes, they are common and they are really useful!

But if they are fragile, then they will always feel like a bit of a hack. The fundamental problem of equating functions which "do the same thing", e.g. so that (x...) -> f(x...) == f, will probably never be solved. I don't know how to progress beyond that, but it would be nice to find a way to do this kind of thing.

[nalimilan]

I think the current design assumes that function-based implementations are optimizations, but should implement the same behavior as the default broadcast version. I guess @stevengj can confirm.

[stevengj]

Yes, @nalimilan. Overriding broadcast for particular functions should ordinarily not be done, and at most should be done as an optimization only.

Because of fusion, it will never be possible to guarantee that broadcast(::typeof(f), ...) is called for a particular f. For example, consider x .* y .* z — this will get lowered to broadcast((x,y,z) -> x*y*z, x,y,z), meaning that a specialized broadcast(::typeof(*), ...) method will not be called.

(In addition to that, there are some internal optimizations to the lowering for repeated symbols, numeric literals, etcetera, aimed at expressions like @. (3x+4x^2-6)/(x^2 + 1). That's what @malmaud noticed above. But even if we removed these optimizations, the fusion would still remain.)

[stevengj]

Note that broadcast methods in GPUArrays are entirely different, because they are for broadcast(f::Function, ...) on any f — this is entirely appropriate to define for custom container types.

(GPUArrays probably should have used a generated function to handle arbitrary mixtures of scalars and numbers, and in general we should make broadcast easier to overload for custom container types, but that is a separate issue.)

[mlubin]

CC @madeleineudell jump-dev/Convex.jl#192 (comment)

There's a workaround in ArrayFire.jl: https://github.com/gaika/ArrayFire.jl/blob/master/src/array.jl#L130

By overriding broadcast() and saving the state in a global variable it is possible to do something different.