[SciPy-dev] new function regrid for fitpack2

John Travers jtravs at gmail.com
Thu Oct 12 18:48:56 CDT 2006

Hi Stefan,

First, about the segfaults - I can submit a ticket, but it basically
stems from surfit not liking interpolation (even the fortran only
versions segfault). Using regrid+method for scattered data should deal
with this problem.

In my enthusiasm I started two threads. In the newer thread I mention
that delaunay triangulation can be used for interpolating scattered
data. So I'm thinking of combining the delaunay package from the
sandbox with regird from fitpack to make a general interp2d function
which should work well in most cases.

On 12/10/06, Stefan van der Walt <stefan at sun.ac.za> wrote:
> I have a couple of concerns:
> 1. I recently made some changes to the interp2d interface in order to
>    make the coordinate specification more consistent.  Your patch
>    simply reverts to the older behaviour.  I don't like this because
>    it assumes that x values increase with rows and y values with
>    columns, even though this isn't mentioned anywhere in the
>    docstrings.  I'm not suggesting that the alternative is better, but
>    it does make fewer assumptions -- it simply flattens the x and y
>    inputs and pass them to the fitpack routine (unless x*y != z.size,
>    in which case it makes up a meshgrid).

The reason I changed this is because 'regrid' can only take 1d x,y
arrays which have the same number of points as the respective axis of
z. Flattening doesn't work here. It probably isn't hard for interp2d
to take either coordinate arrays, mgrid matrices, meshgrid matrices or
ogrid arrays and for us to detect which axis they are varying in and
then get things right for regrid. But as per my note above, when we
get scattered data working too we can deal with the input issues
better. In the mean time I think it is better to have just regrid

> 2. The docstrings were updated to be fairly descriptive, whereas after
>    patching we'd be back to short, non-descriptive documentation.

I tried to only remove things that were no longer relevant (like the
input array format). But if we change as per above, we should
re-instate your docs. (I don't mean to tred on toes...). I can make
clearer docstrings for the temporary regrid only interp2d first.

> I'm also not happy about the way the output shape is determined (but
> this is a shortcoming of the current version, not a problem with your
> patch).  Again, do x values increase along rows or columns?  One
> option which overcomes this problem is for the output to be the same
> as the argument to __call__, i.e.
> x([[0,1,2],[3,4,5],[6,7,8]],[[0,1,2,],[3,4,5],[6,7,8]])
> returns a (3,3) array of values, whereas
> x([0,1,2],[0,1,2])
> returns a (3,) array of values, unlike the current (3,3).
> Unfortunately, this doesn't allow the usage of ogrid.  Ultimately, it
> doesn't really matter as long as we choose an axis system and document
> it clearly.

Agreed. I always use columns = x. But we should be more flexible.

> I'd also like to see some tests to verify the behaviour of the new
> interp2d that is *different* from the old version.  It's easier to add
> it now, while everything is still fresh in our memories.

Will try and do this tomorrow.

> We can probably sort out these issues with minimal effort.  Thanks a
> lot for working on interp2d -- it has been long overdue for an
> overhaul.


More information about the Scipy-dev mailing list