Convenience constructors

[chiyahn]

Here I have added some convenience constructors that can be used to create interpolation objects in an accessible way as suggested in #206 (comment). Note that they support multidimensional cases as well; see unit tests located at test/convenience-constructors.jl for some examples.

[lstagner]

This is great. However, I think it would be better to make the extrapolation behavior a keyword argument. Something like

LinearInterpolation(ranges::NTuple{N,T}, vs; bc = Interpolations.Throw()) where {N,T <: Range} = extrapolate(scale(interpolate(vs, BSpline(Linear()), OnGrid()), ranges...),  bc)

[jlperla]

@lstagner I agree with you. Though I think that in general the approach should be to make the basics easy, and let people stick with the full interface when they want to do anything fancy.

But with that logic, I do think that throwing vs. non-throwing is sufficiently important to be made easy... having the throwing adds about a 1/4 performance overhear from our quick tests, so it would be very nice to get things working with default Throw to ensure hidden bugs don't creep in, and then easily turn them off when you want to tweak the performance.

[jlperla]

@ChrisRackauckas @sglyon Here are the convenience constructors for feedback. If you have any early comments tell us and we can tweak it before a merge is appropriate. This is probably the last of the Interpolation.jl tweaks we are planning for now.

[jlperla]

@chiyahn Do you think this is ready to go if there is a little documentation? If so, you could add in a few very simple examples below the General Usage in the README.md that shows

• LinearInterpolation with 1D with a regular grid
• LinearInterpolation in 1D with an irregular grid
• CubicSpline in 1D with a regular grid
• LinearInterpolation with 2D and a regular grid?

I think that is about it, we can keep the convenience constructor examples very simple and tell people to use the full API otherwise?

[tomasaschan]

Maybe also in the examples pick one and show how to configure extrapolation. Maybe also have one test for that.

The tests could probably be expressed more concisely by, instead of actually interpolating stuff, just creating one interpolation object using the convenience constructor and one using the full API, and then verifying that they have the same type. That way, the tests also act as extra documentation for how to go between the two representations.

But with that, all green lights from me!

[sglyon]

One other question would be whether or not we want to control boundary conditions on Cubic splines? Right now I believe they are set to always use Line, but we could make that a keyword argument if we wanted .

[jlperla]

@tlycken All your suggests sound great to me.

@sglyon is your thinking that we would do something like

CubicSplineInterpolation(ranges::NTuple{N,T}, vs; bc = Interpolations.Line(), extrapolation_bc = Interpolations.Throw()) where {N,T <: Range} = extrapolate(scale(interpolate(vs, BSpline(Cubic(bc)), OnGrid()), ranges...), extrapolation_bc)

Do you like those names for the keywords?

If so, I think it is a reasonable addition. At that point, we are probably at the point where if people want additional features they should use the full interface?

[jlperla]

@sglyon @lstagner @tlycken @ChrisRackauckas : Does anyone have any other comments or todos on this PR? I believe this implements all of the feedback to date?

If people are generally happy with it, then maybe we could start a ticking clock on the PR, with a plan to tag a release of the library combining these constructors and the () access?

[chiyahn]

One more last thing -- added an extra parameter for boundary conditions in CubicSplineInterpolation as @sglyon suggested 😃

[sglyon]

This looks good to me!

Thanks.

Starting a clock now. Will merge within 24 hours unless I see something here

[lstagner]

The quick start guide needs to be updated to use the function call syntax.

[chiyahn]

That's right; here I made a PR for revision: #216. Thanks for the reminder!