ArrayPartition broadcast() assumes input and output types are the same

[rdeits]

broadcast(f, x::ArrayPartition) always tries to return a result of the same type as x, which can create some odd behaviors and errors:

julia> using RecursiveArrayTools

julia> x = ArrayPartition([1, 2], [3.0, 4.0])
RecursiveArrayTools.ArrayPartition{Tuple{Array{Int64,1},Array{Float64,1}}}(([1, 2], [3.0, 4.0]))

julia> broadcast(y -> y + pi, x)
ERROR: InexactError()
Stacktrace:
 [1] convert(::Type{Int64}, ::Float64) at ./float.jl:679
 [2] setindex! at ./multidimensional.jl:247 [inlined]
 [3] macro expansion at ./broadcast.jl:154 [inlined]
 [4] macro expansion at ./simdloop.jl:73 [inlined]
 [5] macro expansion at ./broadcast.jl:147 [inlined]
 [6] _broadcast!(::##5#6, ::Array{Int64,1}, ::Tuple{Tuple{Bool}}, ::Tuple{Tuple{Int64}}, ::Array{Int64,1}, ::Tuple{}, ::Type{Val{0}}, ::CartesianRange{CartesianIndex{1}}) at ./broadcast.jl:139
 [7] broadcast_c! at ./broadcast.jl:211 [inlined]
 [8] broadcast!(::Function, ::Array{Int64,1}, ::Array{Int64,1}) at ./broadcast.jl:204
 [9] macro expansion at /home/rdeits/.julia/v0.6/RecursiveArrayTools/src/array_partition.jl:102 [inlined]
 [10] broadcast!(::##5#6, ::RecursiveArrayTools.ArrayPartition{Tuple{Array{Int64,1},Array{Float64,1}}}, ::RecursiveArrayTools.ArrayPartition{Tuple{Array{Int64,1},Array{Float64,1}}}) at /home/rdeits/.julia/v0.6/RecursiveArrayTools/src/array_partition.jl:100
 [11] broadcast(::##5#6, ::RecursiveArrayTools.ArrayPartition{Tuple{Array{Int64,1},Array{Float64,1}}}) at /home/rdeits/.julia/v0.6/RecursiveArrayTools/src/array_partition.jl:107

julia> broadcast(y -> true, x)
RecursiveArrayTools.ArrayPartition{Tuple{Array{Int64,1},Array{Float64,1}}}(([1, 1], [1.0, 1.0]))

Fixing this seems challenging (and possibly not worthwhile right now), but I figured I'd bring it up anyway.

[ChrisRackauckas]

Thanks for finding this. For DiffEq usage, this isn't a big deal at all because this kind of type changing would lead to type-instabilities (and broadcast! is the main one used anyways). But, this should get fixed anyways. However, since it's not very DiffEq-relevant, that puts it lower on the priority list (for me, PRs are always welcome).

[rdeits]

Yup yup, sounds good.