Collaboration?

[timholy]

Hi Elvind,

This looks like a really interesting package. You might not be aware of the Grid package (https://github.com/timholy/Grid.jl), which largely focuses on uniform B-splines. @tlycken (with a little help from me) is working on a more flexible and performant rewrite, https://github.com/tlycken/Interpolations.jl. There's no documentation yet, but if you're curious you can glance over the issues which include links to ipython notebooks.

I haven't looked carefully at your code yet, but I wonder if there's room for collaboration. One possibility is to keep separate packages for uniform and non-uniform interpolation; at a minimum, we should see if the interfaces can be made as compatible as possible, and keep each other apprised of issues. Another is to put them together into a single package, which might help ensure uniformity. My brief glance at your code suggests it's quite sophisticated but somewhat in the mold of Grid's design, and I think over the course of time we learned some lessons about how to do even better. A good issue for reading is timholy/Grid.jl#38.

Thoughts, everyone?

[TheBB]

Hi Tim,

I noticed that package but I couldn't find it again when I was writing the README.

I agree, it would be good to get interfaces to conform. I've only implemented basis objects so far, so the public facing interface of my package is largely a blank sheet. I'm also not opposed to more thorough collaboration, but I might continue fiddling with this in either case, since it's also a learning project.

If you get a chance to look at my code in more detail I would appreciate it. I am new to Julia and I have probably committed a number of performance violations. :-) And now that you mention it, maybe I should implement cardinal splines as a special case, for speed.

[timholy]

I'll be happy to look it over in more detail, at some point.

Regarding the learning experience, I'll point out that since Interpolations is also in-progress, there's plenty of implementation & learning to be done for us all. In general I find that working with other people tends to enhance, rather than diminish, the learning experience. You seem to have somewhat different strengths from us, and so I am sure we'd all learn from each other.

I assume you know this already, but it's possible for multiple people to have direct push access to the same repository, so it's not like combining on a single package would slow anyone down. Likewise, having two separate packages also doesn't eliminate the possibility of collaboration, especially if we all contribute to each others' packages.

Of course, there are advantages & disadvantages either way: for users, load times are shorter if you load less functionality, which is somewhat in favor of splitting. For developers, one disadvantage is that it's harder to share infrastructure.

[TheBB]

Yeah, those are all valid points. I will have a look at Interpolations.

[tomasaschan]

I'm all for collaboration =)

However, I must admit that I threw myself into the interpolation business simply because it was functionality I needed at the time, and I'm by no means an expert on it. I haven't come in contact with much of the NURBS terminology at all before (and scarcely worked with interpolation at all, save using it for other stuff) so I'm learning a lot as I go along - much thanks to Tim, who's ever so patient with me when I get stuck.

My hopes for the Interpolations.jl package is that it can, in a quite distant future, become a package that gathers many different interpolation types and styles under one umbrella; starting with B-splines was simply a practical choice, given what already existed in the ecosystem. If I understand correctly, NURBS can be viewed as a generalization of the concept of B-splines, so I think it would be really interesting to see if it's possible to generalize the approach in Interpolations.jl to cover this as well. With that in mind, I think it would be awesome if we could have merging the packages into one as, at least, a long-term goal. (However, I have no clue whether this generalization effort is feasible at all, since the math behind NURBS is still beyond my understanding...)

The basic interface in Interpolations.jl at the moment is centered around three core pieces:

• The Interpolation constructor, which takes an array A of data points (where the underlying data grid is implicitly 1:size(A,dim) for each dimension) and a set of configuration objects, all of which are singleton type instances (to allow multiple dispatch to work as efficiently as possible).
• Extension of Base.getindex to work on interpolation objects, to allow evaluation at arbitrary points, and
• The configuration type hierarchy, with contains types that define e.g. the degree of the interpolating splines polynomials, boundary conditions and extrapolation behavior.

There will also, as soon as I get to it, be methods like gradient and hessian that evaluate derivatives similarly to how getindex evaluates function values (but without the fancy itp[x] syntax, of course). Thus, functionality-wise it seems like the overlap between (future) Interpolations.jl and the B-spline specialization in (future?) NURBS.jl is almost total.

I've already started thinking about renaming the Interpolation type to BSpline, and define a function interpolate(A::Array, configs...) that is responsible for creating the interpolation object, to make room for other interpolation types as well. So it would be quite easy to make room for NURBS interpolation in the same interface - just specify a new set of configuration types, and we're there. I haven't looked closely at your code yet, but I assume that creating a wrapper that constructs a NURBS interpolation object this way would be quite straightforward.

If we don't want to put it all in the same package (yet), we could also split out part of Interpolations.jl into a package with basic stuff (like the interpolate function) that both our packages can use and extend, to make a merge as seamless as possible later. (This approach was taken by e.g. the stats family of packages a while ago, and seems to have been quite successful as far as providing a common interface is concerned.)

Sorry for the wall of text - I get a little excited when I get to talk about code with others =)

[TheBB]

NURBS are generalizations of B-splines, but they are generally not used for interpolation (at least not over here). B-splines do that just fine. You use NURBS when you need to have an exact representation of a shape that B-splines can't give you, typically conic sections. Since you know what you're after a priori there's no need to interpolate.

A typical use case for me is something like this. Make a surface that is a B-spline shape on one end, NURBS shape on the other, and linear interpolation inbetween.

somecurve = interpolate(mypoints, :bsplines) :: BSplineCurve
circlesegment = mkcirclesegment(center, axis, angle) :: NURBSCurve
surface = loftbetween(somecurve, circlesegment) :: NURBSSurface

The loftbetween function has to elevate somecurve to NURBS type and must produce a NURBS result because of the circle segment. This is the kind of thing I was hoping to do in this package. I can't get away from doing regular B-spline interpolation though, because that is (overwhelmingly) how you get the “building blocks.”

So in a sense, at the interpolation stage, where you have “incomplete” information already, there's no reason to favour NURBS over B-splines.

I should note that operations such as loftbetween require compatibility between the knot vectors of somecurve and circlesegment, which is why I also need nonuniform interpolation. Often I (as the end user) can get around this by being careful, but it's enough of a burden that I don't want to have to worry about it.

[timholy]

Right, I think the point of overlap is in the non-uniform interpolation. That's a feature that was never well-developed in Grid, mainly because it's not very important for my own work. But it's certainly important functionality for the community as a whole. If you have a need for non-uniform interpolation, that presents a great chance to get that implemented nicely.

A lot of the more specific operations you describe do seem best for a standalone package that might make use of Interpolations.

[tomasaschan]

OK, thanks for the explanation!

Non-uniform interpolation is definitely on my wishlist for Interpolations.jl, although I haven't yet looked closely enough at the problem to be able to say how, or when, it will be implemented. However, if you have some specific requirements on the API to be able to utilize Interpolations.jl, it's definitely possible to take that into account and make sure that you can use Interpolations for whatever B-splines you need for NURBS; nothing of Interpolations' API is set in stone (yet).