# [SciPy-user] Fwd: interpolation question

Michael Hearne mhearne@usgs....
Wed Oct 24 09:51:20 CDT 2007

```John - I guess I have a different bias - in Matlab (and now numpy)
I've always thought of rows being in the y direction, and columns as
being in the x direction.  This explains my confusion with the x and
y parameters.

I also just figured out what the rest of my problem was - more
confusion with x and y when extracting the interpolated results.

You may rest easy, or as much as you can while finishing off your
thesis!

Is it uncommon to think of columns as being in the x direction, and
rows in y?

--Mike
On Oct 24, 2007, at 7:02 AM, John Travers wrote:

> Hi Micheal,
>
> On 23/10/2007, Michael Hearne <mhearne@usgs.gov> wrote:
>> Haven't heard any discussion on this issue since I posted last
>> week - are
>> these in fact bugs or am I not using the module correctly?
>
> I do want to look at and solve these issues, but I'm extremely busy at
> the moment finishing off my thesis, so haven't got too much time to
> spend on it!
>
>> I do have one more question - when I use the code with a non-
>> square grid, I
>> get an error saying that my x data does not match the x dimension
>> of my z
>> data.
>>
>> In looking at the following code, it seems like x is being
>> compared with the
>> number of rows of Z data, and y being compared with the number of
>> columns:
>
> [snip]
>
>> Isn't numpy row-major like Matlab?  I.e, The first dimension is
>> that of
>> rows, the second is that of columns?
>
> numpy is generally row-major I think. However a lot of scipy is
> written in fortran and so the implementation may leak through. I think
> this is the case with these functions.
>
> However, I'm not quite sure I understand your problem. If you have a
> 2d array of data with m rows and n columns (i.e. m in first index, n
> in second) then I would expect to call a procedure like
> RectBivariateSpline with 1d arrays of length m and n, in that order.
> Does this not make sense? What is referred to as x and y is arbitrary
> right? In this case x just refers to the first dimension rather than
> fastest changing dimension.
>
> Anyway, the underlying code is in fortran and from a quick look at the
> source of fitpack2 I don't see any special treatment of x,y axes in
> any of the bivariate spline procedures so I suspect that the fortran
> convention is reflected directly in (this part) of scipy. Have you
> checked the other 2d spline functions like SmoothBivariateSpline etc?
>
>> I also found that if I modify the code in fitpack2.py (see below)
>> to compare
>> dimension[0] with Y and dimension[1] with X, I still get back
>> interpolated
>> results whose dimensions are opposite of what was specified (rows =>
>> columns, columns=> rows).
>
> This is because the actual interpolation is performed in the base
> class of all of the bivariate spline procedures, see the __call__
> method of BivariateSpline for this. As I noted above this convention
> will be across all of the bivariate spline methods. Is it not also
> reflected in interp2d?
>
> Maybe I will understand your problem better if you give me a short
> code example which shows the issue. I'll then discuss it with other
> scipy developers and see if a consensus can be agreed upon about
> whether this is a bug that should be fixed or simply a convention to
> be observed. There is a slight problem in that this code is now 4
> years in use (though RectBivariateSpline only about a year) and so
> changing it now may not be possible due to backards compatibility.
>
> I'll try and consider this in more detail when I get more time!
>
> Best regards,
> John
> _______________________________________________
> SciPy-user mailing list
> SciPy-user@scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-user

------------------------------------------------------
Michael Hearne
mhearne@usgs.gov
(303) 273-8620
USGS National Earthquake Information Center
1711 Illinois St. Golden CO 80401
Senior Software Engineer
Synergetics, Inc.
------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...