BUG: interpolate.interp2d would ignore three of its arguments #361

wants to merge 1 commit into


None yet

2 participants


This should solve #1072 and #1444. I've yet to update the tests, but please tell me if this the right way to go, as I have a few questions remaining.

  • I changed the docstring's meaning of copy=False to not promise a reference to be stored. This matches the old behavior. The reference/copy is useless anyway, as it's never used. Maybe we should get rid of the x, y, z members and document copy as being a no-op, only accepted for compatibility with interp1d?
  • The proposed code is backwards-incompatible. Should we add an extrapolate argument (or accept bounds_error="extrapolate") to get the old behavior back?
  • Finally, should the bounds be public or private (leading _) attributes? Does SciPy have any conventions that I should follow here?
@pv pv commented on the diff Nov 20, 2012
z = fitpack.bisplev(x, y, self.tck, dx, dy)
z = atleast_2d(z)
z = transpose(z)
+ z[out_of_bounds] = self.fill_value
pv Nov 20, 2012 SciPy member

I don't think this works as intended? The fill value is assigned only according to the first axis?

larsmans Nov 20, 2012

You're right. It works in the 1-d case, but I didn't test the 2-d case. Will fix.

pv Feb 3, 2013 SciPy member

This assignment to z[out_of_bounds] does not work as intended --- z has shape (len(x), len(y)), whereas out_of_bounds has shape (nx,).

SciPy member
pv commented Nov 20, 2012

Yep, I think some new tests are needed here.

Having fill_value=None signal extrapolation (and having that as the default) could be another alternative --- I think I like it more than having string arguments in bounds_error. Backward compatibility probably should be preserved here.

For class attributes not part of API, I'd personally prefer having an underscore prefix, but I'm not sure existing code should be changed to follow this. Of course, if it's "if undocumented, then private" is another rule.

(For Scipy module and function/class names my preference for _ prefix is stronger, because this helps people to see more clearly what may change in the future, and what probaly not. Case in point: there's loads of code out there importing stuff from Scipy's sub-submodules...)


Personally, I'd find overloading bounds_error easier to read and more explicit ("if a bounds error occurs, then just extrapolate") than overloading fill value (which would signal "if a bounds error occurred, then fill with None"), also because None becomes np.nan when assigned to a Numpy array element.

What to do with the x, y, z attributes? They were entirely undocumented, so can they be removed?

SciPy member
pv commented Nov 20, 2012

I suppose the x, y, z attributes are not widely used by existing code, so they probably could be removed. On the other hand, at least x and y may come useful in some cases, so there's also a rationale for preserving (and documenting) them.

Re: bounds_error / fill_value --- as long as backwards compatibility is preserved, any sensible approach works here.


Hm, I've been trying to write a test, but I can't import the Scipy I just built; scipy.special complains about a missing symbol zbesh_. Any idea what that could be? I'm running a pretty vanilla Ubuntu 12.04.

SciPy member
pv commented Nov 21, 2012

rm -rf build, rebuild probably helps.

SciPy member
pv commented Nov 22, 2012

gh-353 touched this part of the code, so you may want to rebase

@larsmans larsmans BUG: interp2d would ignore three of its arguments
Also changed the meaning of copy=False to not *promise* a reference
to be stored. The reference/copy is useless anyway.
SciPy member
pv commented Feb 3, 2013

Revised version merged in c3cc0ee

@pv pv closed this Feb 3, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment