Allow manual override of return type for fillvalue

[timholy]

I'm playing with ForwardDiff as a way of computing gradients, and needed this to handle the fact that sometimes the same FilledExtrapolation object gets called with two different types of indexes (Float64 and GradientNumber{Float64,...}). I added these lines (the last one being the relevant one here) to my own code:

# Some necessary ForwardDiff extensions
Base.real(v::ForwardDiff.GradientNumber) = real(v.value)
Base.ceil(::Type{Int}, v::ForwardDiff.GradientNumber)  = ceil(Int, v.value)
Base.floor(::Type{Int}, v::ForwardDiff.GradientNumber) = floor(Int, v.value)
# Type-stability in gradient computation
@generated function Interpolations.fillvalue{T<:ForwardDiff.GradientNumber}(val, args::T...)
    :(ForwardDiff.GradientNumber(val, args[1].partials.data))
end

and now ForwardDiff works fine.

[tomasaschan]

I thought this was the purpose of exporting the FilledExtrapolation constructor, or am I misunderstanding something? Can all the goals of these two things be accomplished with just one of them?

[timholy]

It was, but that's a static mechanism. What if you call the same FilledExtrapolation object with two different types of indexes? For example, itp[-3.2] might give you NaN, but itp[dual(-3.2,1.0)] (with the same itp) should give you dual(NaN, 1.0).

[timholy]

Though I suppose we could use the promote_op mechanism instead?

[tomasaschan]

My question was not as much "do we need this?" as "do we need both, or can this replace the other?" but if both are valuable I see no reason not to keep them both anyway. So it was more a curious question than criticism :)

But using promote_op sounds like a good idea to me - otherwise we'll basically re-implement a mechanism for the user to do the same thing, but hard-coded (and thus error-prone). Perhaps we can accomplish something similar to how we calculate T when creating B-spline interpolation objects, and/or the array type for gradient (see below, soon to be included in the PR for extrapolation behaviors)?

@generated function gradient{T,N}(itp::AbstractInterpolation{T,N}, xs...)
    n = count_interp_dims(itp, N)
    Tg = promote_type(T, [x <: AbstractArray ? eltype(x) : x for x in xs]...)
    :(gradient!(Array($Tg,$n), itp, xs...))
end

Regardless of what the actual solution ends up being, I think we should try to a) make sure that we are compatible with the promotion mechanisms in base Julia as much as possible, and b) make the user-interface as seamless ass possible. Leveraging promote_op to accomplish a) can probably help with b), so that's a good place to start :)

[tomasaschan]

Btw, the test failure should be fixed once #73 is merged.

[timholy]

OK, see if you like this better (I do).

I deleted the docs for FilledExtrapolation, since they focused on controlling the return type (which has proven to be of very limited utility). Should we un-export the type, or leave it?

[tomasaschan]

Should this initialization be done some other way?

[timholy]

This test can probably just be dropped, since it was really testing explicit control.

[tomasaschan]

Should we un-export the type, or leave it?

Since exporting the type was mainly to make the type-controlling constructor available, I think we should probably un-export it. (That's a very simple breaking change to work around, should there be anyone who has already started using it - just say FilledExtrapolation = Interpolations.FilledExtrapolation and you're done...) Un-exporting also gives symmetry to other types, where almost no types - except the different configuration "flags" - are exported from the rest of the library.

[timholy]

Thanks for the review (and catches). Should be addressed now. There's some weird SSL error on nightly (I restarted, and that didn't fix it), but I doubt it reflects a problem with this PR.

[timholy]

All package PRs are failing this way today.

[tomasaschan]

All package PRs are failing this way today.

😿

[timholy]

Merge anyway? (I can't, it won't let me.)

[tomasaschan]

I assume this is since JuliaLang/julia#11196 merged, and that it'll keep being broken until the regressions are fixed. I also assume this might take a while..:

I'll disable the build on nightly for now; after that, restarting the build should make it pass and allow merging (I'm using Github's semi-new "protect branch" feature on master, to prevent merging before checks pass, but it probably doesn't make sense to require that everything passes on a very unstable Julia master...).

[tomasaschan]

See #75.

[tomasaschan]

Rebasing this onto current master should fix the build (by not trying on 0.5...).