Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature wishlist #5

Closed
15 of 17 tasks
tomasaschan opened this issue Nov 21, 2014 · 24 comments
Closed
15 of 17 tasks

Feature wishlist #5

tomasaschan opened this issue Nov 21, 2014 · 24 comments

Comments

@tomasaschan
Copy link
Contributor

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)

Extrapolation behaviors

Interpolation degrees

Other functionality

@timholy
Copy link
Member

timholy commented Nov 23, 2014

Looks good! One point I'm not sure about is why you separate boundary conditions from extrapolation behavior; it basically seems like one follows from the other.

@timholy
Copy link
Member

timholy commented Nov 23, 2014

One more topic of importance: efficient multi-valued interpolation (e.g., timholy/Grid.jl#44). Obviously this will just "drop out" for people who use Arrays of immutables, but for other cases (like the one in that issue) one might need another approach.

My current thinking is that this is a case where it's best to wait for Julia to support fixed-size arrays efficiently, and not try to hack around this in Interpolations.jl. In the meantime, people who need that can use Grid. As a close facsimile, we could conceivably support arrays of tuples.

@tomasaschan
Copy link
Contributor Author

Multi-valued interpolation is important indeed, but I'm more and more leaning toward supporting this simply by duck typing, and forcing the user to use other tools to get their data in an appropriate shape. As we've said previously somewhere, we currently only demand that the data type supports multiplication with floats and addition (i.e. are basically vectors in some vector space...), and I would argue that reshaping data that is in some other form (i.e. an image in an Array{T,3}, the third dimension being color spaces) is out of scope for Interpolations.jl.

Re: bc/extrap separation, there are basically two reasons: one is that they are basically independent in the implementation, so it seems like a bad idea to couple them more than necessary in the API, and the other is that we have a couple of extrapolation behaviors that don't map nicely to boundary conditions (e.g. ExtrapError), and it's therefore better to let the user specify them independently. For many BCs, we could probably have a constructor that selects a corresponding extrapolation behavior, so the users don't have to say e.g. Periodic twice.

@timholy
Copy link
Member

timholy commented Nov 23, 2014

but I'm more and more leaning toward supporting this simply by duck typing

that's basically what I'm saying, too. (Your version is clearer, though.)

Re the boundary conditions: got it. Carry on 😄.

@albop
Copy link

albop commented Nov 25, 2014

The wishlist is promising !
About extrapolation, I also think that it is nice to separate boundary conditions and extrapolation. For some applications, using linear extrapolation, at any order, improves the chances that the extrapolated behavior is not crazy, not returning to zero or wildly diverging.

@TheBB
Copy link
Contributor

TheBB commented Dec 3, 2014

Typical boundary conditions used for cubic splines are:

  • Free: continuous third derivatives in the second and second-to-last points.
  • Natural: zero second derivative at the boundaries.
  • Tangent: specific derivatives at the end. This is a special case of Flat. It would be good to have an inhomogeneous Flat type for this, and let Flat = Tangent(0, 0) or something along those lines.

@tomasaschan
Copy link
Contributor Author

@TheBB Thanks for the input! I think the natural boundary conditions will be identical to a linear BC, since the way to implement the latter is also to set the second derivative to zero at the boundary. I'll update the wishlist with the other two.

@kzapfe
Copy link

kzapfe commented Apr 10, 2015

I have some of a theorical/implementation question:
Why packages such as Pyplot have such a large set of interpolation routines to plot functions over 2D domains ("images") and on the other hand turns out to be so cumbersome to implement the same interpolations "just to the data"? What I am missing here?
I think I have the same problem as other people here: I need continous, reliable Hessians for my work. I see what can I understand of your package and see if I can contribute. Keep the splendid work!

@tomasaschan
Copy link
Contributor Author

@kzapfe PyCall/PyPlot are of a very specific type of Julia packages - they're both wrappers for code in other languages that have had much more time than Julia to evolve and mature. Thus, comparison to pure Julia packages like Interpolations.jl isn't quite "fair" to either type of package. Since PyPlot is built specifically for showing things on-screen, it's maybe not so surprising that it focuses its efforts on 2D. Did you have any other packages with the same limitations in mind?

It's also a much larger problem to write general code that works in any number of dimensions than to write for just one case, so if you only need 1D and 2D there's no reason to build something more general.

That said, you can probably find a lot of good interpolation code in various languages that already has been/would be easy enough to wrap in Julia and that does what you need.

My ambition with this library is to, eventually, eliminate the need for calling out to other languages, at least if you don't need something very specific - but part of the reason for building it is to have an excuse to practice Julia programming :)

@abahm
Copy link

abahm commented Oct 4, 2015

This looks great - thanks for all your work! I'm looking at a task that would require barycentric Lagrange interpolation, which might fit here. Is anyone already working on this?

@tomasaschan
Copy link
Contributor Author

@abahm Not that I know of. If you feel up to it, a PR is always welcome :) The API should probably be something like that for gridded interpolation, e.g. interpolate(knots, data, Lagrange) or even interpolate(knots, data, Lagrange(Barycentric)) to make room for regular Lagrange interpolation too.

@sglyon
Copy link
Member

sglyon commented Oct 20, 2015

I'm going to try to get my hands dirty with cubic splines! I might reach out for help if I get stuck, hope you don't mind.

@sglyon
Copy link
Member

sglyon commented Oct 20, 2015

Also, as I go would you be OK with me trying my best to add docstrings to currently undocumented functions? That would help me learn what everything does.

@tomasaschan
Copy link
Contributor Author

@spencerlyon2 Great! I'm really excited about this project :)

Docstrings are great (we have already discussed moving most of the documentation into them, and away from the Readme, see #46) - but you might also find the documentation in doc/latex useful when figuring out how the current B-spline functionality fits together. I'd love if you could add a few sections for the cubic spline interpolation as well (you can probably copy most of the text, and just update the matrix equations).

My main concerns with this library is that the API stays consistent, and keeps leaving room for incorporating new interpolation schemes, and that we ensure that the composability that we have between the current implementations of b-splines, extrapolation and scaling, is kept for other schemes as well. Together with Tim's focus on squeezing out every single ounce of performance I really think we've found a sweet spot :) I have the ambition of helping you shape your contributions to fit well into this framework. I'm telling you this to make it clear from the start that I do value your contributions - and then I hope you'll have some patience if I'm nit-picky sometimes in my code review... ;)

Feel free to file issues with questions whenever you need it - we'll do our best to answer them promptly.

@timholy
Copy link
Member

timholy commented Oct 20, 2015

Yeah, this sounds fantastic. Do shout for help if you find any of the metaprogramming-heavy stuff confusing.

@greimel
Copy link

greimel commented Mar 6, 2017

Is there a way of performing cubic spline interpolation on a non-uniform grid with this package?

If no, is there a specific reason? It seems to me that the generalization from uniform grid to a non-uniform should be independent of the uniform interpolation scheme.

My workaround so far looks like

function itp_nonuniform(val::Real, itp_uniform, x, y)
    i = 2
    while val > x[i]
        i += 1
    end
    λ = (val - x[i-1])/(x[i] - x[i-1])

    itp_uniform[i - 1 + λ]
end

itp_nonuniform(vals::AbstractVector, itp_uniform, x, y) =
    broadcast(val -> itp_nonuniform(val, itp_uniform, x, y), vals)

Some illustration

using Interpolations, Plots

N = 40
xmax = 2*round(π, 4)

x = xmax * [0; sort(rand(N-2)); 1]
y = sin.(x)

itp_uniform = interpolate(y, BSpline(Cubic(Natural())), OnGrid())

scatter(x, y, label="true")
vals = linspace(0, xmax, 5*N)
plot!(vals, itp_nonuniform(vals, itp_uniform, x, y), label="interp")

EDIT: I probably should've read #131 before my comment. My workaround is most likely doing something different than gridded cubic spline interpolation.

@dagap
Copy link

dagap commented Apr 3, 2017

One thing that would be nice to have is also sinc interpolation.

@sglyon
Copy link
Member

sglyon commented Apr 5, 2017

Thanks @dagap I've opened a separate issue #145

@babaq
Copy link

babaq commented Dec 16, 2017

i wish this package include smooth splines too. recently i tried to convert some R code to Julia which uses R smooth.spline function. The Dierckx.jl can do smooth spline, but the only parameters is a smoothness. R version accept degree of freedoms which is very useful to control not only smoothness but also the complexity of the spline. right now i am using RCall, but hope to replace the hack some day.

another thought is why not use callable overload to sugar coat the interpolation. Dierckx.jl makes the splines callable, so instead of s[newx], i found it more natural to consider the splines as a function s(newx) since most of the time, we use it to fit a smooth functions. of course, this can be added easily, is there any confusions were both be added?

@yakir12
Copy link
Contributor

yakir12 commented May 4, 2018

I'll second @babaq's wish/need for a smoothing functionality.

I will admit though, that it is arguable if smoothing an interpolating object is within the scope of what an interpolating library does. The main objection I can think of is that once you smooth the interpolation it isn't interpolating between the data points any more. The fact remains though that people come looking for some smoothing functionality when interpolating. As the main interpolation package for Julia, I think there should be some information about smoothing the interpolation/data:

  1. why Interpolations.jl doesn't do it
  2. some suggestions on where and how to do it somewhere else
    Ideally there would be some companion package that does it...

@PallHaraldsson
Copy link
Contributor

@gerlero Should monotonic, i.e. https://github.com/gerlero/PCHIPInterpolation.jl be on the list here?

I used PCHIP from SciPy at the time when I needed it (and extrapolation) and it wasn't then available in Julia (when porting from MATLAB). Maybe it makes sense to add that package as a dependency (I believe its BSD license may be compatible with MIT here), not to reimplement. If not add it as a forth alternative in the README?

@mkitti
Copy link
Collaborator

mkitti commented Jun 21, 2022

be on the list here

No. Please create a new issue.

@mkitti mkitti closed this as not planned Won't fix, can't repro, duplicate, stale Jun 21, 2022
@PallHaraldsson
Copy link
Contributor

I rather just added a doc to README #493, at least for now. Did you for sure mean to close since 2 of the tasks not yet completed?

@mkitti
Copy link
Collaborator

mkitti commented Jun 21, 2022

Necroposting on an 8-year old issue where most of the participants have moved on is simply not helpful. For the current maintainers it is also very hard to find and track.

@JuliaMath JuliaMath locked as resolved and limited conversation to collaborators Jun 21, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests