DataInterpolations.jl
DataInterpolations.jl copied to clipboard
refactor: methods for higher dim arrays
- [x] QuadraticInterpolation
- [x] LagrangeInterpolation
- [x] AkimaInterpolation
- [x] ConstantInterpolation
- [x] QuadraticSpline
- [x] CubicHermiteSpline
- [x] QuinticHermiteSpline
- [ ] Derivatives
- [ ] Integrals
- [ ] Show methods for higher dim arrays
- [ ] Add tests for all
This adds methods for BSplines: https://github.com/SciML/DataInterpolations.jl/pull/349
Cool, I will add the rest.
There is one more issue that needs to be added to the checklist. The show methods fail when in Array{T, N} N >= 3
Yes, I am aware about that. Added it to the checklist.
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
reduce(hcat, u) is a fairly expensive operation.
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:
https://github.com/SciML/DataInterpolations.jl/blob/76c545b0607bb477846464033bbbad20a7f8e65b/src/interpolation_caches.jl#L522
And the complexity of this reduce(hcat) is the same as reduce(hcat, u) .
Similarly for BSplines: we do a matrix division right here:
https://github.com/SciML/DataInterpolations.jl/blob/76c545b0607bb477846464033bbbad20a7f8e65b/src/interpolation_caches.jl#L662
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.
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.