Broken extrapolation with integer interpolation

[DaniGlez]

I'm not sure if integer interpolation is something intended to be supported by the package; i.e. for integer u, you can define a ConstantInterpolation - other interpolations get you a non-integer by definition. If so, this is broken as of 7.0.1

julia> itp = ConstantInterpolation([1, 2], [0.0, 10.0]; extrapolation_right=ExtrapolationType.Constant)
ConstantInterpolation with 2 points, in left direction
┌──────┬─────┐
│ time │   u │
├──────┼─────┤
│  0.0 │ 1.0 │
│ 10.0 │ 2.0 │
└──────┴─────┘


julia> itp(5.0)
1

julia> itp(15.0)
2.0

The reason is that the extrapolation code path (

DataInterpolations.jl/src/interpolation_methods.jl

Line 15 in c4de75e

elseif extrapolation_left == ExtrapolationType.Constant

) does

    elseif extrapolation_right == ExtrapolationType.Constant
        slope = derivative(A, last(A.t))
        last(A.u) + zero(slope * t)

where both terms inside the zero(_) call turn into floats. Is there any drawback to just returning last(A.u) in that branch? Obviously this is fairly niche usage, but maybe there's other legitimate type combinations where analogous issues happen.

[DaniGlez]

Funnily but unfortunately, in the last PR @SouthEndMusic added a test that would have caught this already if it weren't true that 2.0 == 2 (should probably change this to a ===)

DataInterpolations.jl/test/interpolation_tests.jl

Line 526 in c4de75e

@test itp(1.0) == 2

[SouthEndMusic]

Me and @visr are also interested in extrapolation of integer constant interpolation.

I vaguely remember why I implemented this like this: some type inference tests (I think for LinearInterpolation because that type is tested into oblivion) failed if I didn't add the slope term. We could do some dispatching on the eltype of u to fix this.

[DaniGlez]

I tried it and it indeed fails to stably infer the output for some LinearInterpolation tests. Which makes sense, because with the current implementation then you'd have different output types (same as u or depending on the types of u and t) depending on the value (not the type) of the extrapolation flag. The solutions I see are

1. Refactoring the interpolation structs to have the extrapolation flag be a type parameter instead, which feels a bit overkill
2. Specialize extrapolation dispatch instead on ConstantInterpolation itself, where you could even drop support for extrapolations that depend on the derivative.

[SouthEndMusic]

I'd say option 2 is the nicest indeed