Broadcast inexact issues

[TotalVerb]

broadcast seems to have a good chunk of inexact problems that its cousin map does not. This seems to be because promote_op (and by extension promote_eltype_op, which broadcast uses) believes that functions return the same type that they receive by default. To me this behaviour is a little strange.

> sin.([1, 2, 3])
ERROR: InexactError()
 in macro expansion at ./broadcast.jl:95 [inlined]
 in macro expansion at ./cartesian.jl:64 [inlined]
 in (::Base.Broadcast.#_F_#2)(::Array{Int64,1}, ::Array{Int64,1}) at ./broadcast.jl:90
 in broadcast!(::Function, ::Array{Int64,1}, ::Array{Int64,1}) at ./broadcast.jl:213
 in broadcast(::Function, ::Array{Int64,1}) at ./broadcast.jl:220
 in eval(::Module, ::Any) at ./boot.jl:225
 in macro expansion at ./REPL.jl:92 [inlined]
 in (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:46

The two-argument promote_op in int.jl tries executing function on one and one, and uses that type as the result type. I think this behaviour is better than assuming functions are all T => T functions. That this promote_op is smarter is evident when comparing log and log10:

julia> log.(10, 1:10)
10-element Array{Float64,1}:
 0.0     
 0.30103 
 0.477121
 0.60206 
 0.69897 
 0.778151
 0.845098
 0.90309 
 0.954243
 1.0     

julia> log10.(1:10)
ERROR: InexactError()
 in macro expansion at ./broadcast.jl:77 [inlined]
 in macro expansion at ./cartesian.jl:64 [inlined]
 in (::Base.Broadcast.#_F_#8)(::Array{Int64,1}, ::UnitRange{Int64}) at ./broadcast.jl:73
 in broadcast!(::Function, ::Array{Int64,1}, ::UnitRange{Int64}) at ./broadcast.jl:213
 in broadcast(::Function, ::UnitRange{Int64}) at ./broadcast.jl:220
 in eval(::Module, ::Any) at ./boot.jl:225
 in macro expansion at ./REPL.jl:92 [inlined]
 in (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:46

[yuyichao]

Dup of #4883

[timholy]

The key question is whether it's acceptable to use type-inference to pick the correct return type. Historically the answer has been "no," which means this is a hard problem. PRs that make it better are welcome. (Note the substantial rewrite of broadcast in #16260, however.) EDIT: I should also say, I know how much you've already been contributing, @TotalVerb! That comment was not intended in any way other than welcoming of all ideas.