refactor: methods for higher dim arrays

[sathvikbhagavan]

• QuadraticInterpolation
• LagrangeInterpolation
• AkimaInterpolation
• ConstantInterpolation
• QuadraticSpline
• CubicHermiteSpline
• QuinticHermiteSpline
• Derivatives
• Integrals
• Show methods for higher dim arrays
• Add tests for all

[ashutosh-b-b]

This adds methods for BSplines: #349

[sathvikbhagavan]

Cool, I will add the rest.

[ashutosh-b-b]

There is one more issue that needs to be added to the checklist. The show methods fail when in Array{T, N} N >= 3

[sathvikbhagavan]

Yes, I am aware about that. Added it to the checklist.

[ashutosh-b-b]

Do we need to write different dispatches for Vector{Vector} implementation of BSplines? Essentially we can get away with:

BSplineInterpolation(u::AbstractVector{<:AbstractVector}, args...; kw...) = BSplineInterpolation(reduce(hcat, u), args...; kw...)
# Same for BSplineApprox

[ChrisRackauckas]

reduce(hcat, u) is a fairly expensive operation.

[ashutosh-b-b]

reduce(hcat, u) is a fairly expensive operation.

But in existing methods we do it anyways. For example in the method for CubicSplines{Vector{Vector}} we do a reduce(hcat, d) down here:

DataInterpolations.jl/src/interpolation_caches.jl

Line 522 in 76c545b

d = transpose(reshape(reduce(hcat, d_), :, n + 1))

And the complexity of this reduce(hcat) is the same as reduce(hcat, u) .
Similarly for BSplines: we do a matrix division right here:

DataInterpolations.jl/src/interpolation_caches.jl

Line 662 in 76c545b

c = vec(sc \ u[:, :])

which will need a reduce(hcat) over all vector of vectors.

Meanwhile, all of this happens during the construction of the interpolation function. So we donot loose on performance while actually interpolating.

[ChrisRackauckas]

Doing it once for construction is fine.

But note that only works for the linear algebra. If you do that, you will change the type of the output, so something like a ComponentArray will loose its type and structure.