[SciPy-dev] interp2d and sandbox/delaunay
jtravs at gmail.com
Mon Oct 16 12:14:18 CDT 2006
On 16/10/06, Robert Kern <robert.kern at gmail.com> wrote:
> John Travers wrote:
> > OK, we have a patch waiting for putting regrid into interp2d. The
> > delaunay code in the sandbox looks like it is fine for the scattered
> > data. So our new interp2d should call regrid for regular data, and use
> > natural neighbour interpolation from delaunay for scattered data. I
> > can submit a patch for this, but we need delaunay out of sandbox for
> > this to work. (and it means interpolate will depend on another
> > module).
> I am very much against interp2d() doing different algorithms. Each algorithm
> should be exposed as separate functions. Even though my data is regular, it is
> entirely possible that I would want to use natural neighbor interpolation anyways.
OK, so the user can specify the method and we simply note in the docs
that spline interpolation isn't available for scattered data?
> > Speaking about the current module setup, we should really actually
> > have a scipy.approximation.spline (contents of fitpack, currently in
> > interpolate) module. At the moment it is just confusing (calling
> > scipy.interpolate.fitpack2.SmoothBivariateSpline for smoothing and not
> > interpolation???) then we could also have
> > scipy.approximate.smooth2d() and leave scipy.interpolate with interp1d
> > etc.
> That's not a bad idea.
> > Anybody have any comments on this? Is delaunay ready to be moved, how
> > about the module reorganisation (would break api).
> I think the API is stable, and I think most of the bugs have been shaken out. I
> would like to replace the underlying Delaunay triangulation algorithm with a
> Guibas-Stolfi divide-and-conquer algorithm using robust geometric predicates,
> but I'm still implementing that slowly. Also, the error handling in the C++ was
> implemented very naively and should be replaced. However, neither of those
> issues would affect the external use of the module (except perhaps by making it
> more robust), and probably don't need to hold up moving the module out of the
> sandbox if there is a great need for it. An impartial reviewer might disagree
> with me, of course. :-)
Well, given that the current interp2d doesn't work at all for even
quite small amounts of data I think the sooner the better.
Alternatively, we could setup scipy.sandbox.spline and then write the
new interpolation module under the sandbox for now.
BTW, did you consider using Qhull as the delaunay code? I think the
licence is OK, and it seems to be the "standard" (i.e. octave and
Matlab both use it) and actively maintained.
More information about the Scipy-dev