Inconsistent output eltype when evaluating on vectors

[DaniGlez]

As of 7.1.0, output eltype is different when evaluating on vectors compared to just broadcasting the scalar path

julia> using DataInterpolations
julia> u = [2, 3];
julia> t = [0.0, 1.0];
julia> itp = ConstantInterpolation(u, t)
julia> itp(t)
2-element Vector{Float64}:
 2.0
 3.0

julia> itp.(t)
2-element Vector{Int64}:
 2
 3

The culprit is in the following lines from https://github.com/SciML/DataInterpolations.jl/blob/master/src/DataInterpolations.jl#L29

function (interp::AbstractInterpolation)(t::AbstractVector)
    u = get_u(interp.u, t)
    interp(u, t)
end

function get_u(u::AbstractVector, t)
    return similar(t, promote_type(eltype(u), eltype(t)))
end

For floats versus ints, a specialization can be defined for ConstantInterpolation (whose output is the one that actually preserves the eltype of u). But I wonder if the promotion would also generate issues with exotic output types. Would it be possible for get_u to use the inferred return type of interp itself or would that require usage of arcane Julia internals?

[Ickaser]

This promotion does indeed generate issues with Unitful types. If u and t have different dimensions (e.g. length and time), then the promotion gives a generic Quantity rather than a concrete unit type. In this case, it doesn't result in an error, but it does mean the vector doesn't have a concrete type any more.

(This same kind of promotion is the culprit of errors for derivative and integral evaluations as in #385 ).

[devmotion]

Would it be possible for get_u to use the inferred return type of interp itself or would that require usage of arcane Julia internals?

IMO usually it's a bad idea to replicate or even outsmart the logic of the compiler. In such a a general case you can't get it completely right in my experience, there are just too many special cases. This promotion is also highly problematic for non-numeric types you might want to use with ConstantInterpolation. AFAICT the best default would just be to not fall back to the inplace method at all.

[DaniGlez]

IMO usually it's a bad idea to replicate or even outsmart the logic of the compiler. In such a a general case you can't get it completely right in my experience, there are just too many special cases. This promotion is also highly problematic for non-numeric types you might want to use with ConstantInterpolation. AFAICT the best default would just be to not fall back to the inplace method at all.

Yeah, I meant more or less the opposite, i.e., getting the inferred type which I think it's still internal functionality and not recommended, in any case. Either way it was just a guess to preserve the in-place code path, personally I don't see anything wrong with your map approach, which does not require eltype-juggling.

[devmotion]

These internal functions are allowed to return basically any supertype of the result and give up at any point and return Any. It's also allowed to change at any point in time. Hence in my experience the best is either to directly use existing functionality such as map or to compute the result for one element, create a container based on the result, and then fill it with the remaining results. But the latter seems unnecessarily complex here.