broadcast picking incorrect result type

[stevengj]

The following code fails with an InexactError():

X = [1,2,3]
Y = [4 5]
broadcast(atan2, X, Y)

whereas

[atan2(x,y) for x in X, y in Y ]

(albeit producing an array of type Any), while

atan2([1,2,3],[4,5,6])

produces an array of Float64.

Can we improve the type inference so that all three cases can generate Float64 arrays? Note that this is needed for #4363 (for @vectorize_2arg to use broadcast).

[toivoh]

There's really no way for broadcast to know that atan2 will produce a float result from int arguments, until some kind of type inference (upper bound inference?) is exposed to Julia code. But if you look in broadcast.jl, there is broadcast_T{T}(op::Function, ::Type{T}, As::StridedArray...), which takes a result type as well, and a companion broadcast_T_function(op::Function) to create a specialized op_broadcasted_T(::Type{T}, As::StridedArray...). So if someone is willing to put in some work to define the mapping of input to output types, this is doable already.

I didn't export broadcast_T because I didn't want to bloat the exports to much, but maybe it should be exported and documented. (Of course, broadcast! already allows to specify the result type through through the type of the destination)

[stevengj]

@toivoh, but how does atan2([1,2,3],[4,5,6]) do it? It looks like it is just an untyped comprehension in @vectorize_2arg, which means that Julia has the logic somewhere to infer the type...

[JeffBezanson]

Comprehensions contain a special bit of magic. It is arguably the ugliest thing in the language. We will have a more general version of it eventually.

One can also do things like Array(typeof(f(x[1],y[1])), ...) but this isn't perfect either.

[stevengj]

Can't broadcast be written to exploit the comprehension magic, at least in common cases?

[stevengj]

Duplicate of #16164

[stevengj]

As I commented in #16164, it seems that map is now able to do the right thing, so we need to adapt the map algorithm to broadcast.