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@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 working.
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.
Thanks. John