juliamath / interpolations.jl

Fast, continuous interpolation of discrete datasets in Julia

Interpolations.jl

This package implements a variety of interpolation schemes for the Julia language. It has the goals of ease-of-use, broad algorithmic support, and exceptional performance.

Currently this package supports B-splines and also irregular grids. The API has been designed with intent to support more options. Initial support for Lanczos interpolation was recently added. Pull-requests are more than welcome! It should be noted that the API may continue to evolve over time.

At the bottom of this page, you can find a "performance shootout" among these methods (as well as SciPy's RegularGridInterpolator).

Installation

Interpolations.jl can be installed via the following invocation since it is a registered Julia package.

using Pkg
Pkg.add("Interpolations")

Example Usage

Create a grid xs and an array A of values to be interpolated

xs = 1:0.2:5
A = log.(xs)

Create linear interpolation object without extrapolation

interp_linear = linear_interpolation(xs, A)
interp_linear(3) # exactly log(3)
interp_linear(3.1) # approximately log(3.1)
interp_linear(0.9) # outside grid: error

Create linear interpolation object with extrapolation

interp_linear_extrap = linear_interpolation(xs, A,extrapolation_bc=Line()) 
interp_linear_extrap(0.9) # outside grid: linear extrapolation

Other Examples

More examples, such as plotting and cubic interpolation, can be found at the convenience constructions documentation.

Other Interpolation Packages

Other interpolation packages for Julia include:

• ApproXD.jl implements B-spline and linear interpolation in Julia.
• BarycentricInterpolation.jl implements the Barycentric formula for polynomial interpolation on equispaced points and Chebyshev points of the first and second kind.
• BasicInterpolators.jl provides a collection of common interpolation recipes for basic applications.
• BSplineKit.jl offers tools for B-spline based Galerkin and collocation methods, including for interpolation and approximation.
• Curves.jl supports log-interpolation via immutable Curve objects.
• DataInterpolations.jl is a library for performing interpolations of one-dimensional data.
• Dierckx.jl is a wrapper for the dierckx Fortran library, which also underlies scipy.interpolate.
• DIVAnd.jl for N-dimensional smoothing interpolation.
• FastChebInterp.jl does fast multidimensional Chebyshev interpolation on a hypercube using separable grid of interpolation points.
• FEMBasis.jl contains interpolation routines for standard finite element function spaces.
• FineShift.jl does fast sub-sample shifting of multidimensional arrays.
• FourierTools.jl includes sinc interpolation for up and down sampling.
• GeoStats.jl provides interpolation and simulation methods over complex 2D and 3D meshes.
• GridInterpolations.jl performs multivariate interpolation on a rectilinear grid.
• InterpolationKernels.jl provides a library of interpolation kernels.
• KissSmoothing.jl implements denoising and a Radial Basis Function estimation procedure.
• LinearInterpolations.jl allows for interpolation using weighted averages allowing probability distributions, rotations, and other Lie groups to be interpolated.
• LinearInterpolators.jl provides linear interpolation methods for Julia based on InterpolationKernels.jl, above.
• LocalFunctionApproximation.jl provides local function approximators that interpolates a scalar-valued function across a vector space.
• NaturalNeighbours.jl provides natural neighbour interpolation methods for scattered two-dimensional point sets, with support for derivative generation.
• PCHIPInterpolation.jl for monotonic interpolation.
• PiecewiseLinearApprox.jl performs piecewise linear interpolation over an arbitrary number of dimensions.
• ScatteredInterpolation.jl interpolates scattered data in arbitrary dimensions.

Some of these packages support methods that Interpolations does not, so if you can't find what you need here, check one of them or submit a pull request here.

If you would like to list a registered package that is related to interpolation, please create a Github issue.

Performance shootout

In the perf directory, you can find a script that tests interpolation with several different packages. We consider interpolation in 1, 2, 3, and 4 dimensions, with orders 0 (Constant), 1 (Linear), and 2 (Quadratic). Methods include Interpolations BSpline (IBSpline) and Gridded (IGridded), methods from the Grid.jl package, methods from the Dierckx.jl package, methods from the GridInterpolations.jl package (GI), methods from the ApproXD.jl package, and methods from SciPy's RegularGridInterpolator accessed via PyCall (Py). All methods are tested using an Array with approximately 10^6 elements, and the interpolation task is simply to visit each grid point.

First, let's look at the two B-spline algorithms, IBspline and Grid. Here's a plot of the "construction time," the amount of time it takes to initialize an interpolation object (smaller is better):

The construction time is negligible until you get to second order (quadratic); that's because quadratic is the lowest order requiring the solution of tridiagonal systems upon construction. The solvers used by Interpolations are much faster than the approach taken in Grid.

Now let's examine the interpolation performance. Here we'll measure "throughput", the number of interpolations performed per second (larger is better):

Once again, Interpolations wins on every test, by a factor that ranges from 7 to 13.

Now let's look at the "gridded" methods that allow irregular spacing along each axis. For some of these, we compare interpolation performance in both "vectorized" form itp[xvector, yvector] and in "scalar" form for y in yvector, x in xvector; val = itp[x,y]; end.

First, construction time (smaller is better):

Missing dots indicate cases that were not tested, or not supported by the package. (For construction, differences between "vec" and "scalar" are just noise, since no interpolation is performed during construction.) The only package that takes appreciable construction time is Dierckx.

And here's "throughput" (larger is better). To ensure we can see the wide range of scales, here we use "square-root" scaling of the y-axis:

For 1d, the "Dierckx scalar" and "GI" tests were interrupted because they ran more than 20 seconds (far longer than any other test). Both performed much better in 2d, interestingly. You can see that Interpolations wins in every case, sometimes by a very large margin.

Development Status

This package is being maintained but not actively developed. Maintenance is focused on fixing bugs and issues with the current code base. New features are welcome via pull requests and will be reviewed and released in a timely fashion.

If you would like to become involved in maintenance or active development of the package please feel free to get in touch via a Github issue.

This package follows semantic version in that documented features should not break without changing the minor version.

See the news for details on how to update between breaking releases, indicated by changes in minor versions.

Contributing

Work is very much in progress, but help is always welcome. If you want to help out but don't know where to start, take a look at issue #5 - our feature wishlist =) There is also some developer documentation that may help you understand how things work internally.

Contributions in any form are appreciated, but the best pull requests come with tests!

interpolations.jl's Issues

Interploation of Float32 array returns Float64

julia> typeof(interpolate((1.0:2, 1.0:2), rand(Float32,2,2), Interpolations.Gridded(Linear()) )[1.5,1.5])
Float64

Not the end of the world but maybe fixable?

Note that it works for BigFloats:

julia> typeof(interpolate((1.0:2, 1.0:2), convert(Matrix{BigFloat},rand(2,2)), Interpolations.Gridded(Linear()) )[1.5,1.5])
BigFloat

Documentation overhaul

This is to discuss changes to, and completion of, documentation for this package. Major questions are:

• How do we want to organize the documentation? Formats, locations etc...
• What should be documented (more than just by writing clear code)? Devdocs? Implementation details?
• On what level of detail do we want to document things?

Some discussion started in #45 already, where the following points were raised:

In a sense the README could be a summary of what's available, now that

julia> using Interpolations
julia> ?Interpolations

dumps the README contents. So I've begun to think that it might be good to keep the README as an "API reminder" for people who already understand the package, and the IJulia notebook as an introduction to the package.

I agree that it's probably a good idea to make the readme minimalistic. I'd also like to start documenting most other things in a help>-compatible way, so we might want to move off from the IJulia notebooks alltogether. And I feel like I have to strip down the LaTeX stuff to something with minimal dependencies, so anyone can at least compile it, but it is a very handy way to document the mathematical background of any methods we implement...

Issue with Interpolations on JuliaBox

Hello,
First of all, thank you for writing the package "Interpolations". I'm currently working on JuliaBox (at my workplace it is very difficult to install new programs!!). However, I'm having trouble loading the package.
When I try to add the package (julia>Pkg.clone("https://github.com/tlycken/Interpolations.jl.git")
​I get the following:
​
INFO: Cloning Interpolations from https://github.com/tlycken/Interpolations.jl.git
Interpolations already exists
while loading In[12], in expression starting on line 1
in error at error.jl:21
in clone at pkg/entry.jl:148
in clone at pkg/entry.jl:175
in anonymous at ./pkg/dir.jl:28
in cd at ./file.jl:20
in cd#228 at ./pkg/dir.jl:28
in clone at pkg.jl:30

And when I try to use the package (julia> using Interpolations)
I get the following:

syntax: extra token "getindex" after end of expression
while loading /home/juser/.julia/v0.3/Interpolations/src/Interpolations.jl, in expression starting on line 170
while loading In[11], in expression starting on line 1
in include at ./boot.jl:245
in include_from_node1 at ./loading.jl:128
in reload_path at ./loading.jl:152
in _require at ./loading.jl:67
in require at ./loading.jl:52

Pre-allocated interpolation

I am using AffineTransform to transform a large number of volumes and the interpolation process allocated a huge amount of memory. I know there is a interpolate! function. However interpolate! would destroy the input matrix. Also it looks like it can only be used with BSpline(Quadratic(InPlace())). Is there a way to output the interpolation to a pre-allocated matrix but also keep the input matrix? Thanks!

Display of interpolation objects is broken (soon...)

julia> using Interpolations

julia> A1 = rand(3)
3-element Array{Float64,1}:
 0.305873 
 0.0887733
 0.981168 

julia> i1 = Interpolation(A1, Linear(OnGrid()), ExtrapError())
[3]-element Interpolation{Float64,1,Linear{OnGrid},ExtrapError}Error showing value of type Interpolation{Float64,1,Linear{OnGrid},ExtrapError}:
ERROR: type: writemime: in typeassert, expected Int64, got Array{Int64,1}
 in writemime at replutil.jl:19
 in display at REPL.jl:117
 in display at REPL.jl:120
 in display at multimedia.jl:149
 in print_response at REPL.jl:139
 in print_response at REPL.jl:124
 in anonymous at REPL.jl:586
 in run_interface at ./LineEdit.jl:1379
 in run_frontend at ./REPL.jl:818
 in run_repl at ./REPL.jl:169
 in _start at ./client.jl:400

It works on master, but will break as soon as #9 merges. I have no idea what I did to break it. @timholy, any ideas?

Bug in gradient evaluation near edges?

Given the following,

using Interpolations
xs = -pi:2pi/20:pi
itp = interpolate(sin(xs), BSpline(Quadratic(Periodic)), OnGrid)

using Gadfly
plot(x=xs, y=[gradient(itp,x)[1] for x in xs], Geom.path)

I think we ought to be able to do better than this at the edges:

Just to make sure that this is related to edge-proximity, and not to the fact that the function tends to 0 in this specific case, I tested with the boundaries at [-3pi/4, 5pi/4] too, with similar results:

I'll see if I can do some troubleshooting, but I'm putting this up here to indicate that we at least know about the problem.

Hermite splines?

A recent post on julia-users made a case for Cubic Hermite splines, that seem to have some properties that regular B-splines might not have (although I must admit that I'm not too familiar with the terminology used in the julia-users thread...).

Cubic Hermite splines are quite similar to B-splines, but instead of using several data points to construct an interpolating polynomial, the derivatives at the data points are used instead. It readily generalizes to irregular grids, which is nice, but I can't find any good resources on whether it generalizes nicely also in dimensions.

Vector-valued evaluation

Looking at #5, this is one of very few things left to do before we might call ourselves ready for a version 0.1.

I still think this makes sense only in a multi-linear context; the following is probably a good method definition for that:

getindex{T,N}(itp::Interpolation{T,N}, NTuple{N,AbstractVector}...)

Of course, it's going to have to be more specific in order to avoid ambiguity errors. I'm thinking we might not have to specify the type of the vector elements at all - we'll get method errors in the next stage anyway, if the user supplies some nonsensical index vector.

Incorporation of functionality from GridInterpolations.jl

GridInterpolations.jl provides multivariate interpolation on a rectilinear grid with support for both multilinear and simplex interpolation. My lab does interpolation in an inner-inner loop for a dynamic programming application, and so quite a bit of effort was put into making it fast. It would be neat if this functionality can be migrated to Interpolations.jl without compromising on speed or the simplicity of the interface.

Hessian fails for function of two variables

In converting over some code that currently uses Grid.jl, I need to compute the curvature of a surface. The following REPL transcript illustrates the problem I'm having:

julia> A = rand(5,5)
5×5 Array{Float64,2}:
 0.264768   0.405079  0.253461  0.759207  0.673105
 0.0884208  0.528674  0.244601  0.545683  0.751446
 0.403174   0.68685   0.722238  0.746143  0.42529
 0.396175   0.651159  0.909525  0.402493  0.251807
 0.130116   0.986705  0.259471  0.51158   0.850608

julia> itp = interpolate(A, BSpline(Cubic(Natural())), OnGrid())
5×5 Interpolations.BSplineInterpolation{Float64,2,Array{Float64,2},Interpolations.BSpline{Interpolations.Cubic{Interpolations.Line}},Interpolations.OnGrid,1}:
 0.264768   0.405079  0.253461  0.759207  0.673105
 0.0884208  0.528674  0.244601  0.545683  0.751446
 0.403174   0.68685   0.722238  0.746143  0.42529
 0.396175   0.651159  0.909525  0.402493  0.251807
 0.130116   0.986705  0.259471  0.51158   0.850608

julia> h = hessian(itp,2.0,2.0)
ERROR: UndefVarError: dim not defined
 in hessian_coefficients(::Type{Interpolations.BSpline{Interpolations.Cubic{Interpolations.Line}}}, ::Int64, ::Int64, ::Int64) at c:\home\simonp\.julia\v0.5\Interpolations\src\b-splines\indexing.jl:18
 in hessian_impl(::Type{Interpolations.BSplineInterpolation{Float64,2,Array{Float64,2},Interpolations.BSpline{Interpolations.Cubic{Interpolations.Line}},Interpolations.OnGrid,1}}) at c:\home\simonp\.julia\v0.5\Interpolations\src\b-splines\indexing.jl:123
 in hessian!(...) at c:\home\simonp\.julia\v0.5\Interpolations\src\b-splines\indexing.jl:144
 in hessian(::Interpolations.BSplineInterpolation{Float64,2,Array{Float64,2},Interpolations.BSpline{Interpolations.Cubic{Interpolations.Line}},Interpolations.OnGrid,1}, ::Float64, ::Float64) at c:\home\simonp\.julia\v0.5\Interpolations\src\b-splines\indexing.jl:153

This was run using Julia 0.5.0 and Interpolations 0.3.6. Note: I get the same error using OnCell() and when checking out the master version of Interpolations. Is hessian supposed to work for surfaces?

Thanks,
--Peter

Gridded Interpolation Seems broken

I am trying to use the gridded interpolation for a look up table with a linear and logspaced axis, however I'm not getting past the initial documentation tests.
A = rand(8,20)
itp = interpolate(A, Gridded{Linear})
yields the following error:

ERROR: MethodError: interpolate has no method matching interpolate(::Array{Float64,2}, ::Type{Interpolations.Gridded{Interpolations.Linear
}})
Closest candidates are:
interpolate{TWeights,TCoefs,IT<:Union{Interpolations.BSpline{D<:Interpolations.Degree{N}},Tuple{Vararg{Interpolations.BSpline{D<:Interpola
tions.Degree{N}}}}},GT<:Union{Interpolations.GridType,Tuple{Vararg{Interpolations.GridType}}}}(::Type{TWeights}, ::Type{TCoefs}, ::Any, ::Ty
pe{IT<:Union{Interpolations.BSpline{D<:Interpolations.Degree{N}},Tuple{Vararg{Interpolations.BSpline{D<:Interpolations.Degree{N}}}}}}, ::Typ
e{GT<:Union{Interpolations.GridType,Tuple{Vararg{Interpolations.GridType}}}})
interpolate{IT<:Union{Interpolations.BSpline{D<:Interpolations.Degree{N}},Tuple{Vararg{Interpolations.BSpline{D<:Interpolations.Degree{N}}
}}},GT<:Union{Interpolations.GridType,Tuple{Vararg{Interpolations.GridType}}}}(::AbstractArray{T,N}, ::Type{IT<:Union{Interpolations.BSpline
{D<:Interpolations.Degree{N}},Tuple{Vararg{Interpolations.BSpline{D<:Interpolations.Degree{N}}}}}}, ::Type{GT<:Union{Interpolations.GridType
,Tuple{Vararg{Interpolations.GridType}}}})
interpolate{TWeights,TCoefs,Tel,N,IT<:Union{Interpolations.Gridded{D<:Interpolations.Degree{N}},Tuple{Vararg{Interpolations.Gridded{D<:Int
erpolations.Degree{N}}}}}}(::Type{TWeights}, ::Type{TCoefs}, ::NTuple{N,Union{AbstractArray{T,1},Tuple}}, ::AbstractArray{Tel,N}, ::Type{IT<
:Union{Interpolations.Gridded{D<:Interpolations.Degree{N}},Tuple{Vararg{Interpolations.Gridded{D<:Interpolations.Degree{N}}}}}})

I'm currently trying to discover the proper syntax, but the intro documentation on the front page does not work.
Can someone help me out in the correct call syntax?

Thanks,
Sloan

Exporting Change with @everywhere

I'm not sure where this problem is occurring but it seems localized to Interpolations.
I'm using pmap to execute numerous sub-tasks and I use @Everwhere include("task_execution.jl").
Two places in task_execution in different sub-files an interpolator is created by calling

using Interpolations

and then going through the specification. This has worked for a couple of days, but I restarted my repl and ran Pkg.update() and now something weird is happening.

I get the following warning for each of the worker tasks
WARNING: replacing module Interpolations
WARNING: replacing module Interpolations

and then finally I get this:
ERROR: LoadError: On worker 2:
...,LoadError("C:\dev\julia.julia\v0.4\Interpolations\src\Interpolations.jl",88,LoadError("C:\dev\julia.julia\v0.4\Interpolations\src\scaling/scaling.jl",161,UndefVarError(:Quadratic)))))

in include_string at loading.jl:233
in include_from_node1 at loading.jl:274
in include_string at loading.jl:233
in include_from_node1 at loading.jl:274
in require at loading.jl:210
in include_string at loading.jl:233
in include_from_node1 at loading.jl:274
in include_string at loading.jl:233
in include_from_node1 at loading.jl:274
in eval at sysimg.jl:14
in anonymous at multi.jl:1350
in anonymous at multi.jl:892
in run_work_thunk at multi.jl:645
[inlined code] from multi.jl:892
in anonymous at task.jl:68
in remotecall_fetch at multi.jl:731

...and 3 other exceptions.

in sync_end at task.jl:414
in anonymous at multi.jl:1361
in include at boot.jl:260
in include_from_node1 at loading.jl:271

Running the load again changes the file that's missing.
Hopefully this is enough to identify what is happening. In the mean time I will work on making a dedicated test case.

Specifying the output type of an interpolation object

One of the issues with Grid.jl was that it's hard to specify what type the interpolation object should return - Interpolations.jl should be able to do better if we want it to be easily usable with any number type.

I'm leaning toward an interface with an optional first type argument, that specifies the output type, similar to what round and friends do in 0.4:

julia> itp = Interpolation(Float64, 1:10, Linear(OnGrid()), ExtrapNaN())

julia> typeof(itp[3.2])
Float64

Of course, we need to provide some sensible default, and there are a couple of options:

• Use the element type of the input array, i.e. Interpolation(A, config...) = Interpolation(eltype(A), A, config...)
  Pros:

  • very predictable for the end user; effectively, eltype(Interpolation(A,...)) == eltype(A)

  Cons:

  • will have the same problems as Grid.jl, especially for integer inputs (but these are avoided if the user explicitly sets a type)
  • we have to convert each return value, so there must be a conversion defined from whatever our calculations promote to, to the return type.

• Use use some sensible promotion result, e.g. promote_type(eltype(A), Float64, typeof(x)...) (where the Float64 is from the literals in the prefiltering step - we might be able to avoid those, if we can require a convert method for converting floats to eltype(A))

  Pros:

  • very similar to what we do today
  • won't require anything extra from the user to work with integers, e.g. itp = Interpolation(1:10, ...)

  Cons:

  • might be difficult to get it right, since there are lots of places where numbers enter the calculations
  • might seem unpredictable to the user, especially since e.g. promote_type(Rational{Int}, Float64) == Float64 will make us return floats instead of rationals for Interpolation(A::Array{T<:Rational}, ...)

I honestly don't know what's best here, but before we start implementing this, we need some sort of decisions on:

• What should the API look like? (Is the above suggestion good or ugly?)
• How should we choose a default?

Developer guide

I've been following developments here and Grid.jl for quite some time now (grid for a couple years, this since its inception).

I am going to be working on writing some routines for Chebyshev interpolation and cubic B-splines and would like to contribute them to this package as I feel this is where that code should ultimately belong. The only problem is that I don't have enough time to really dig in and learn all the meta-magic works in this package.

Is there a brief developer guide that explains how the system works and how it can be extended? If there isn't one, might I submit a request that one be written? Thanks!

Implement `hessian`

From Wikipedia:

In mathematics, the Hessian matrix or Hessian is a square matrix of second-order partial derivatives of a scalar-valued function, or scalar field. It describes the local curvature of a function of many variables.

It is basically a (symmetric) matrix of second-order partial derivatives. For scalar-valued function of a scalar, f(x), it is simply the second derivative; for a vector-valued function of a vector, it is

          |  f''_xx(v)     f''_xy(v) |
H(f)(v) = |                          |
          |  f''_yx(v)     f''_yy(v) |

or on component form, H_{i,j} = \frac{\partial^2 f}{\partial x_i \partial x_j} (yes, until #46 is in place you have to render LaTeX in your head. Or read the wiki entry...).

Implementations for lower degrees than cubic are trivial - they should just return 0 everywhere.

Fix integer-valued array inputs

Currently this is broken (and it may be my fault):

julia> using Interpolations

julia> A = rand(1:20, 3, 3)
3x3 Array{Int64,2}:
 19  20   5
 17  19  14
 19   9   9

julia> itp = interpolate(A, BSpline(Quadratic(Flat)), OnCell);
ERROR: InexactError()
 in invert_column! at /home/tim/.julia/v0.4/Interpolations/src/b-splines/../filter1d.jl:38
 in _A_ldiv_B_md! at /home/tim/.julia/v0.4/Interpolations/src/b-splines/../filter1d.jl:21
 in A_ldiv_B_md! at /home/tim/.julia/v0.4/Interpolations/src/b-splines/../filter1d.jl:14
 in prefilter! at /home/tim/.julia/v0.4/Interpolations/src/b-splines/prefiltering.jl:38
 in prefilter at /home/tim/.julia/v0.4/Interpolations/src/b-splines/prefiltering.jl:26
 in interpolate at /home/tim/.julia/v0.4/Interpolations/src/b-splines/b-splines.jl:36
 in interpolate at /home/tim/.julia/v0.4/Interpolations/src/b-splines/b-splines.jl:39

Fix this once #34#36 and #36#37 get merged.

Feature wishlist

Now that basic functionality is in place, we need to extend what we have with more cases, to make the library feature complete. That's a good case for a wishlist =) This issue is intended to keep track of overall progress toward feature parity with (interpolation parts of) Grid.jl - actual implementation details can be discussed in separate issues.

Boundary condtions (assuming a grid on 1:n)

• Flat, i.e. f'(x=1) = f'(x=n) = 0 (#8)
• Line (or Natural), i.e. f''(x=1) = f''(x=n) = 0 (#9)
• Tangent, i.e. with specified derivatives at the edges (Flat is essentially Tangent(0,0))
• Reflect, i.e. all continuous derivatives are 0 at the edge, to preserve continuity properties when extrapolating (Added in #20)
• Periodic, i.e. function value and all derivatives are equal at both edges; with OnGrid, the data should include both cell boundaries (and A[1]==A[end]), while with OnCell this assumption is not necessary (but rather A[-.5] == A[end+.5]) (#9)
• Free, i.e. with extra continuous derivatives close to the edges, to close the system. (For e.g. cubic splines, which have continuous second derivatives, the third derivatives are also continuous at the second-to-last boundaries). (#9)

Extrapolation behaviors

• Constant, i.e. return the value at the closest data point (#8)
• Linear (#23)
• Quadratic etc, valid up to the same degree as the interpolation. When the same degree, just continue the outermost polynomial; when lower degree, construct an extrapolation polynomial with as many continuous derivatives as necessary for a smooth transition. For example, linear extrapolation of a quadratic interpolation object, would have continuous value and first derivative (which conveniently specifies the extrapolation uniquely...).
• Periodic, i.e. f(x + T) = f(x) for a function with period T (#9)
• Reflec, i.e. f(end - 1 + T/3) = f(end - T/3 + 1) (#9)

Interpolation degrees

• Cubic b-splines (#90 - thanks @spencerlyon2!)

Other functionality

• Derivative evaluation, up to the highest continuous degree supported by the interpolation object. E.g. gradient(itp::Quadratic, x) or hessian(itp::Cubic, x). (Gradient fixed in #18, higher orders will be added when higher order interpolations are added...)
• Multi-valued interpolation (i.e. interpolation that yields more than one value per coordinate), More of a decision: do we do anything special to make it easier, or just force users to shape their data accordingly? Discussed separately under #3
• Range/vector-valued indexing (i.e. indexing with multiple values at the same time, e.g. itp[1:.1:10]) (#24, #54, #55)
• Non-uniform interpolation (#11, #56)
• Uniform interpolation on non-unit scales (the same problem that CoordInterpGrid in Grid.jl solves) (#25, #47)

Interpolation over "flat" dimensions

Not sure whether this is an issue or not (there may well be theoretical reasons for why the current state is correct!), but I'm currently interpolating a multidimensional object linearly within a loop, with grids changing in each iteration. In some iterations, the grid can in certain dimensions become "flat", i.e. just a vector containing repeats of the same value. In this case, Interpolations.jl returns NaNs, which at least to me came as a surprise.

When collapsing the grid down to one point (I inserted a line saying (std(gridvals)>0.1) || (gridpoints=1)), an error is raised that dimensions of length 1 are not (yet) supported - is this something that will happen sometime soon? And might it be worthwhile to raise an error if the grid is flat as well, rather than returning NaNs silently, which might be harder to debug?

Improve testing

(With contributions from @tlycken) There is lots of room for improvement in our test suite. Here are some areas that are in need of improvement:

• Vector-valued indexing (ref #24, #54). Test that indexing with arrays, ranges, linranges and linspaces yield the expected results. Test Colon indexing with NoInterp dimensions.
• Exact polynomials (see e.g. discussion in #90). A B-spline of degree n can be tested by interpolating data from a polynomial of the same degree, yielding results that should be exact down to the last ULP. We should test this.
• Boundary conditions: We don't test today that e.g. an interpolant with the Flat boundary condition really has a gradient tending to 0 toward the boundary.

2D irregular interpolation

I have worked out a scheme for linear interpolation of functions f(x,y) that I think might be fast enough to be useful (and might be possible to optimize really well with the same metaprogramming tricks we use on B-splines). It's probably not novel, but I don't know what it's called, so I'm just going to describe it.

Given lists of points (x,y,z) (maybe on the form of equal-length lists xs, ys and zs) representing a discretization of a function z = f(x,y), we can find the value of z at an arbitrary point inside the domain using the following steps:

• Initialization:
  • Create a triangular mesh on the xy-plane
• Evaluation:

  1. Find the three corners of the triangle that contains the sought point (x,y). Let's call them P, Q and R.

  2. Evaluate z as follows:

     A = cross(Q-P, R-P)
     d = dot(A, P)
     z = (d - (x * A[1] + y * A[2])) / A[3]
     

     (These relations follow from finding the equation of the plane through the three points, and then solving for z.)

I would love to have this functionality in the package, and I could take a stab at an implementation (at least as a POC) but I have no idea how to build the triangular mesh. Maybe a Delaunay triangulation is what we want? Is there a package that does that?

Combining knots and NoInterp

I'm trying to use interpolate with knots & NoInterp along some dimension.

• With BSpline, using knots as a first argument returns an error

  A = [0.0593468  0.73381 ; 0.298259   0.135074]
  itp = interpolate((1:2, 2:3), A, BSpline{Linear}, OnGrid)

  I'm not sure whether knots are available for Spline

• With Grid, combining knots and Tuple{Gridded{Linear}, Gridded{NoInterp} returns unexpected results

  A = [0.0593468  0.73381 ; 0.298259   0.135074]
  itp = interpolate((1:2, 2:3), A, Tuple{Gridded{Linear}, Gridded{NoInterp}})
  # itp[1, 2] returns A[1, 2] but should return A[1, 1]
  itp[1, 2]
  #0.7338095900816122

Export `getindex!`

Would it be possible to export getindex! defined here? It's very useful.

problem with 4D example

hi, i'm stuck with this example:

function f(x,y,z,w) 
    sin(sqrt(x^2+y^2)) + (z-w)^3
end
n = 7
space = collect(linspace(-1,1.0,n))
A = [f(x,y,z,w) for x in space,  y in space , z in space,  w in space]
itp = interpolate(A, (BSpline(Linear()), BSpline(Linear()),BSpline(Linear()),BSpline(Linear())), OnGrid())
ERROR: MethodError: `one` has no method matching one(::Type{Any})
 in call at /Users/florian.oswald/.julia/v0.4/Interpolations/src/b-splines/b-splines.jl:27
 in interpolate at /Users/florian.oswald/.julia/v0.4/Interpolations/src/b-splines/b-splines.jl:54
 in interpolate at /Users/florian.oswald/.julia/v0.4/Interpolations/src/b-splines/b-splines.jl:57

Similarly here:

itp = interpolate(A, (BSpline(Quadratic()), BSpline(Quadratic()),BSpline(Quadratic()),BSpline(Quadratic())), OnCell())
ERROR: MethodError: `convert` has no method matching convert(::Type{Interpolations.Quadratic{BC<:Interpolations.Flag}})
This may have arisen from a call to the constructor Interpolations.Quadratic{BC<:Interpolations.Flag}(...),
since type constructors fall back to convert methods.
Closest candidates are:
  convert{T}(::Type{T}, ::T)
  Interpolations.Quadratic{BC<:Interpolations.Flag}(, ::BC<:Interpolations.Flag)
  call{T}(::Type{T}, ::Any)
 in call at essentials.jl:57

thanks

generated function

Not an issue, but, reading the code, I was just wondering why size was a generated function here

@generated function size{T,N,TCoefs,IT,GT,pad}(itp::BSplineInterpolation{T,N,TCoefs,IT,GT,pad}, d)
    quote
        d <= $N ? size(itp.coefs, d) - 2*padextract($pad, d) : 1
    end
end

Isn't it exactly equivalent to this version?

function size{T,N,TCoefs,IT,GT,pad}(itp::BSplineInterpolation{T,N,TCoefs,IT,GT,pad}, d)
    d <= N ? size(itp.coefs, d) - 2*padextract(pad, d) : 1
end

Expose documentation using Documenter.jl

I just heard about Documenter.jl, and I think we should use it :)

Support precompilation

Interpolations.jl doesn't explicitly support Julia precompilation, but it seems like it probably ought to. It should just be a matter of adding

VERSION >= v"0.4.0-dev+6521" && __precompile__()

to src/Interpolations.jl.

This is specifically a problem for me because Gadfly requires KernelDensity which requires Interpolations, so the lack of precompile support here is breaking precompilation of Gadfly for me.

I'll open a PR if this seems reasonable.

Definitions of extrapolation behavior

For some boundary conditions, there are subtle differences in how they are defined that make a big difference in implementation and results. In most cases there's not really one "correct" and one "incorrect" one - I'm just having difficulties determining which definitions would be the most useful, and would like some input from others. (cc @timholy)

• Periodic extrapolation
  For periodic boundary conditions, the code (and behavior) becomes very different whether one expects the input to be periodic including or excluding the periodicity. For example, consider interpolating sin(x):
  
  Should Interpolations.jl expect the red data point to be included or excluded in the input data? If included, should we also require that the first and last data points are equal (in the above case they're not - sin(0) == 0, while sin(2pi) == -2.44929...e-16, i.e. slightly larger than -eps())?
• Reflecting extrapolation
  For reflecting boundary conditions, similar issues arise:
  
  Should we reflect around the end points (magenta) or around the half-interval outside (orange)? If we do the latter, how do we treat the interval between the edge points?

For what it's worth, Grid.jl currently doesn't treat either of these very well - here's for example the same function as for the periodic conditions above, interpolated by Grid.jl:

As seen in the plot, Grid.jl reflects around the half-interval between edges (orange, in the plot above) with a constant interpolation between, and has a 1-step shift for each period with BCperiodic. (Also, neither of them work correctly for negative indices, i.e. to the left of input data...)

Performance of vectorized evaluations

Out of curiosity I just ran some performance comparisons between interpolations.jl and splines.jl. The latter is a small library which does only cubic splines interpolations, in any dimension, with gradient evaluation, and which I updated recently to use julia macros..
I found it it be much faster than interpolations.jl when evaluated on a large number of points, even when compared with interpolations.jl quadratic interpolation. The code to generate the comparison is here: https://github.com/EconForge/splines.jl/blob/master/test/speed_comparison.jl
and here is the output I get on my machine (50x50x50 grid, evaluation on 100000 points):

Comparison (d=3, K=50, N=100000)
interpolations.jl (quadratic)
  0.101063 seconds (1.10 M allocations: 30.527 MB, 5.21% gc time)
splines.jl: 
  0.012379 seconds (6 allocations: 781.469 KB)
splines.jl (with derivatives): 
  0.026054 seconds (11 allocations: 3.052 MB)

Here are a few remarks/questions coming to my mind:

• Where do you think the performance gap come from ? In splines.jl, the iteration over the points happen inside the function. Can it explain all the difference ?
• If I understand correctly, in principle, the evaluation of the splines at all the points could be vectorized with simd inststructions to get more performance gains, but that doesn't seem to happen (in splines.jl), even using "@fastmath @inbounds @simd". Maybe I'm not doing it right. An equialent C code was successfully vectorized by the compiler.
• How hard would it be to replicate the functionalities from splines.jl in interpolations.jl (vectorization, multisplines, gradient) ? Would it be easier to merge splines.jl ?

Improved syntax for gridded/scaled interpolation

If I've got some gridded x and y data already sitting around, its a bit of a pain to interpolate. AFAICT the best way to do it is something like this:

x = [2,4,6,8]
y = [1,4,3,6]

itp = scale(interpolate(y,BSpline(Linear())),x[1]:(x[2]-x[1]):x[end])

Is there some way this could be shortened to something like

itp = interpolate(x,y,BSpline(Linear()))

instead?

Error for Tuple

The following returns an error on the current master (and current master of Julia)

using Interpolations
A = rand(1:10, 10, 10)
interpolate(A, Tuple{BSpline{Linear}, BSpline{Linear}}, OnGrid)

Assertion failed: (i < jl_svec_len(t)), function jl_svecref, file ./julia.h, line 615.

signal (6): Abort trap: 6
__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)
[1]    73071 abort      julia
julia  2.98s user 0.19s system 59% cpu 5.317 total

Monotonic interpolating splines

Thanks for this great package.

It would be nice to add monotonic splines. This is very useful in some situations, e.g. when optimizing over an interpolated function.

See for example splinefun from R for an implementation and some references.

Startup times & stagedfunctions

The load time for the package are fairly long, largely because lots of methods need to be generated. The load time could probably be drastically shortened using stagedfunctions, which allow the methods to be generated on-demand.

If you get to the point where you are ready to switch your development to 0.4, I will gladly convert things over to using stagedfunctions.

extrapolation of Gridded interpolation is wrong

itp = interpolate(([0;10],),[100;110], Gridded(Linear()))

By the way, what is REPL response [101.0 102.0] ?

etp = extrapolate(itp, Flat())
itp[5] # 105.0 OK
etp[5] # 102.0 Buggy

5 is considered as out of [1,2] interval (as documented but not as expected by common users)

cubic spline is not smooth

The following code results in a very jagged plot of the interpolated spline:

using Interpolations
using PyPlot
x = 1:5
y = sin(2*x)
itp = interpolate(y, BSpline(Cubic(Natural())), OnCell())
xi = linspace(1,5,200)
yi = Float64[itp[t] for t in xi]
plot(x,y,"ro")  # Plot the knots as red circles
plot(xi,yi)  # Plot the interpolated cubic spline

I understand that I'm under-sampling the sine function, but nevertheless I expected to get a smooth interpolant. Plot is shown below. Am I misunderstanding something or is this a bug?

Thanks,
--Peter

how do you deal with multidimensional problems?

Hi there,
just wanted to ask how you interpolate a 3D problem, for example, in the Quadratic BSpline case. Do you take the tensor product of the univariate Spline basis functions in each dimension? I couldn't find it in the code. I'd like to talk about this package in a class I'm teaching, so I need to know a bit more.

thanks!

Non-uniform interpolation

I'm opening this issue based on this discussion. I've looked at your source code relatively thoroughly, and I think I understand how it works, even though it's a bit more meta than I'm used to.

Am I correct in assuming that non-uniform interpolation is best represented as a new subtype of GridRepresentation, for example with knot vector as argument to the constructor?

If so, I'd like to start working on that, beginning with constants and working my way up.

Something equivalent to CoordInterpGrid

In order to reach feature parity with Grid.jl, we need something like CoordInterpGrid, that re-scales the interpolation indices to some other coordinate system. This could probably be implemented very similarly to CoordInterpGrid, since the underlying interpolation interface is very similar.

Multi-valued interpolation

One of the things worth considering is "value dimensions" of an array. This was mentioned here. At one point I considered suggesting that any "value dimension" should just be an immutable (like the immutables of Color), but this issue completely dashes that thought (200,000 fields would be a lot of typing...).

So we are left with 3 potential approaches:

• As suggested in the second bullet point, use Arrays as the element types. One problem:

julia> function f(n)
           a = [n]
           nothing
       end
f (generic function with 1 method)

julia> f(3)

julia> @allocated f(3)
64

That's a lot of memory overhead for an element that only needs 8 bytes.

• Use tuples. That limits us to 1d objects, and currently these too have overhead, but I think not as much as Arrays (it's harder to measure because sometimes they are elided, which is of course nice when it's applicable).
• Add a ValueDims<:(Int,...) parameter to the AbstractInterpolation type. This would encode value dimensions in a way that we could dispatch on them. Of course we'd want to do some simple performance testing before adopting this route. Our metaprogramming would have to be even more generic, generating different versions of the code for different choices of the ValueDims tuple.

Uneven Interpolation?

I see this old issue JuliaLang/julia#2557

Has this been resolved in Interpolations.jl?

I.e., can we do unevenly spaced 1D interpolation

Segregation of functionality between BC & Extrap

I have a little time now to get back into this. How do you envision the division between boundary conditions and extrapolation behavior? For example, let's consider the case of 1d interp/extrapolation with grid points at 1:n. Are you thinking something like

abstract BoundaryCondition
immutable BCnone <: BoundaryCondition end    # no constraint on values or derivatives
immutable BCflat_mid <: BoundaryCondition end  # derivative is 0 at 0.5 and n+0.5
immutable BCflat_grid <: BoundaryCondition end  # derivative is 0 at 1 and n
immutable BCline_mid <: BoundaryCondition end # 2nd derivative is 0 at 0.5 and n+0.5
immutable BCline_grid <: BoundaryCondition end # 2nd derivative is 0 at 1 and n

Type Issues - 'convert' has no method matching 'convert'

I've seen this with some of my code as well in v0.4, but right now I can't run any of the examples from the readme:

ERROR: MethodError: `convert` has no method matching convert(::Type{Interpolatio
ns.Gridded{D<:Interpolations.Degree{N}}}, ::Interpolations.Linear)
This may have arisen from a call to the constructor Interpolations.Gridded{D<:In
terpolations.Degree{N}}(...),
since type constructors fall back to convert methods.
Closest candidates are:
  call{T}(::Type{T}, ::Any)
  convert{T}(::Type{T}, ::T)
  Interpolations.Gridded{D<:Interpolations.Degree{N}}(::Type{D<:Interpolations.D
egree{N}})
 in call at essentials.jl:56

This is after I ran this example:

A = rand(8,20)
knots = ([x^2 for x = 1:8], [0.2y for y = 1:20])
itp = interpolate(knots, A, Gridded(Linear()))

Any thoughts?

Throw not exported?

For extrapolation, Throw is not exported, but Flat is. Any reason for this?

`scale` is not type stable

This example:

julia> using Interpolations

julia> itp = interpolate(1:1.0:10, BSpline(Linear()), OnGrid())
10-element Interpolations.BSplineInterpolation{Float64,1,Array{Float64,1},Interpolations.BSpline{Interpolations.Linear},Interpolations.OnGrid,0}:
  1.0
  2.0
  3.0
  4.0
  5.0
  6.0
  7.0
  8.0
  9.0
 10.0

julia> @code_warntype scale(itp, -3:.5:1.5)
Variables:
  itp::Interpolations.BSplineInterpolation{Float64,1,Array{Float64,1},Interpolations.BSpline{Interpolations.Linear},Interpolations.OnGrid,0}
  ranges::Tuple{FloatRange{Float64}}
  #s54::Bool
  #s55::Int64
  d::Int64
  #s12::Bool
  ##xs#7871::Tuple{ASCIIString,Int64,ASCIIString,Int64,ASCIIString,Int64,ASCIIString}
  _var0::Int64
  _var1::Int64
  ##xs#7872::Tuple{ASCIIString,Int64,ASCIIString,Int64,ASCIIString,Int64,ASCIIString}
  _var2::Int64
  _var3::Int64
  ##xs#7873::Tuple{ASCIIString,Int64,ASCIIString,Int64}

Body:
  MANY THINGS OMITTED
 (Interpolations.ScaledInterpolation,Float64,1,Interpolations.BSplineInterpolation{Float64,1,Array{Float64,1},Interpolations.BSpline{Interpolations.Linear},Interpolations.OnGrid,0},Interpolations.BSpline{Interpolations.Linear},Interpolations.OnGrid,Tuple{FloatRange{Float64}})::TYPE{_<:INTERPOLATIONS.SCALEDINTERPOLATION{FLOAT64,N,INTERPOLATIONS.BSPLINEINTERPOLATION{FLOAT64,1,ARRAY{FLOAT64,1},INTERPOLATIONS.BSPLINE{INTERPOLATIONS.LINEAR},INTERPOLATIONS.ONGRID,0},INTERPOLATIONS.BSPLINE{INTERPOLATIONS.LINEAR},INTERPOLATIONS.ONGRID,TUPLE{FLOATRANGE{FLOAT64}}}},itp::Interpolations.BSplineInterpolation{Float64,1,Array{Float64,1},Interpolations.BSpline{Interpolations.Linear},Interpolations.OnGrid,0},ranges::Tuple{FloatRange{Float64}})::INTERPOLATIONS.SCALEDINTERPOLATION{T,N,ITPT,IT,GT,RT}
  end::INTERPOLATIONS.SCALEDINTERPOLATION{T,N,ITPT,IT,GT,RT}

This issue is causing many allocations in a tight loop of my code, which provides motivation for me to investigate. I'll try to resolve the issue soon

Issue running 1D example

When I run:

using Interpolations
nx = 10
f(x) = sin(2pi/(nx-1) * (x-1))
xcoarse = `1:nx`
ycoarse = f(xcoarse);
xfine = 1:.1:xcoarse[end]
yfine = f(xfine);
yitp = interpolate(ycoarse, BSpline(Linear), OnGrid)

I get:

WARNING: sin{T <: Number}(x::AbstractArray{T}) is deprecated, use sin.(x) instead.
 in depwarn(::String, ::Symbol) at ./deprecated.jl:64
 in sin(::FloatRange{Float64}) at ./deprecated.jl:50
 in f(::UnitRange{Int64}) at ./In[1]:4
 in include_string(::String, ::String) at ./loading.jl:471
 in execute_request(::ZMQ.Socket, ::IJulia.Msg) at /home/febbo/.julia/v0.6/IJulia/src/execute_request.jl:177
 in eventloop(::ZMQ.Socket) at /home/febbo/.julia/v0.6/IJulia/src/eventloop.jl:8
 in (::IJulia.##9#15)() at ./task.jl:363
while loading In[1], in expression starting on line 7

LoadError: MethodError: Cannot `convert` an object of type Type{Interpolations.Linear} to an object of type Interpolations.BSpline{D<:Interpolations.Degree}
This may have arisen from a call to the constructor Interpolations.BSpline{D<:Interpolations.Degree}(...),
since type constructors fall back to convert methods.
while loading In[1], in expression starting on line 12

 in Interpolations.BSpline{D<:Interpolations.Degree}(::Type{T}) at ./sysimg.jl:53

I am on Ubuntu 16.04 and

            _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.6.0-dev.508 (2016-09-06 20:36 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit b1f1525 (27 days old master)
|__/                   |  x86_64-linux-gnu

Should I checkout the master Interpolations PKG?

Implement `gradient` for Cubic b-splines

Add Cubic b-splines to benchmarks

We currently have some benchmarks against other packages in the perf folder. These should be updated to include testing of cubic splines.

Potential future problem: rounding mode changed in core Julia

Julia's rounding behavior will change in 0.4 (see JuliaLang/julia#8750 and JuliaLang/julia#9344), and I suspect it might throw off our indexing, since we do things like x_i = round(T, x) to figure out which polynomial we should evaluate. I think it might not be a problem, since ties will coincide with cell boundaries (and thus yield the same value regardless of which cell is used for evaluation), but I'm putting this up here to remember that it might blow up and that I should add tests for it some day.

Anisotropic interpolation (i.e. different specs in different dimensions)

I've encountered a situation where I want to interpolate along some dimensions but not others. I now wonder whether we should make the IT parameter of BSplineInterpolation a tuple, one per dimension of the array. One could use, for example, quadratic interpolation for dimensions 1-2 and linear interpolation along dimension 3, or skip interpolation along some dimensions. If this parameter is a tuple-parameter, then the @generated functions can generate the appropriate getindex code for the type.

Thoughts? We'd of course want there to be an "easy" interface that replicates current behavior, as well as one allowing more control.

Interpolating over a vector of non-integer values raises "ERROR: InexactError()"

Is there a reason why I can vectorize interpolation when using a Gridded Interpolation object and not a plain vanilla B-spline?

using Interpolations

#----------------------------------------------------------------------- 
# B-spline (doesn't work)
#-----------------------------------------------------------------------
# make an array of floats and an interpolation object
J = broadcast(+, collect(linspace(2,5,10)), collect(linspace(1,5,10))' )
J_itp = interpolate(J, (BSpline(Linear()), NoInterp()), OnGrid())

# attempt to interpolate over a vector 
J_itp[linspace(1,2,10),1]
# J_itp[1.5,1]  # a single point works fine 

#-----------------------------------------------------------------------
# works on gridded interpolation just fine though...
#-----------------------------------------------------------------------
knots = (collect(linspace(2,5,10)), [1:10])
J_itp = interpolate(knots, J, Gridded(Linear()))
J_itp[linspace(2,3,10),1]

The interpolation call gives me the following error:

ERROR: InexactError()
in to_index at deprecated.jl:454
in _unsafe_getindex at multidimensional.jl:192
in getindex at abstractarray.jl:488

Great project btw. I hope to help out somehow though I'm not really a julia expert.

Would be good if Interpolations played nicer with SharedArray

I'm very new to Julia so apologies if I'm completely missing something obvious. Please consider this an enhancement request.

I have a use-case where I want to have a bunch of worker processes use samples taken from an interpolate view of a large 3D SharedArray. The access patterns aren't such that I can't split the array up using the distributed array type. However, because interpolate seems to invariably make copies of the shared array (whether to pad the boundaries, or do some pre-filtering I'm not entirely sure) I seem to end up with each worker creating it's own non-shared copy of the same thing, which I don't have enough memory for.

A more detailed write-up with example code can be found at http://stackoverflow.com/questions/38663113/how-to-use-interpolations-on-sharedarray-in-worker-process-without-each-process

I've previously implemented this sort of thing in scipy where the shared array (possibly prefiltered for spline interpolation) can just be forked into the worker processes when a multiprocessing pool is created... but Julia's model seems to be a bit different.

Not sure what the ideal outcome looks like. One of:

• If needed, some code/API change which makes this possible.
• Julia's 0.5 threading will likely make the issue go away as all the threads will presumably be able to hammer on single common interpolate, and no need for SharedArray. Maybe I should just wait for that.
• Is there some way of doing what I'm trying to do already I'm unaware of? The InPlace option to Quadratic interpolation hints at copy-free possibilities... but it seems more akin to scipy ndimage's interpolation's prefiltering... and even if it preserved the sharing, then there's the problem of how get only one worker to do it. Not sure if I've just not quite got the right options to interpolate

Thanks for any suggestions or solutions.