-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
gradient differences between v1.11.0 and v1.13.0 #9401
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Can you print out |
👍 to putting dx back to an array. |
This runs without error for me, so you need to show us the type and shape of >>> x, y = np.meshgrid(np.arange(3), np.arange(3))
>>> np.gradient(x+y, x, y)
[array([[ 1., 1., 1.],
[ 1., 1., 1.],
[ 1., 1., 1.]]), array([[ inf, nan, inf],
[ inf, nan, inf],
[ inf, nan, inf]])] Results look pretty meaningless though |
@eric-wieser, extending your example, is the following expected behaviour? Best I can tell the shapes/types match in this toy... In [119]: print np.__version__
1.13.0
In [106]: x, y = np.meshgrid([4.,6,25], np.arange(3));np.gradient(x+y, x, axis=0)
Out[106]:
array([[ 0.5 , 0.5 , 0.5 ],
[ 0.45739348, 0.45739348, 0.45739348],
[ 0.05263158, 0.05263158, 0.05263158]])
In [107]: type(x+y)
Out[107]: numpy.ndarray
In [108]: type(np.random.randint(0,4,size=(3,3)).astype('float'))
Out[108]: numpy.ndarray
In [109]: z=x+y
In [110]: type(z[0][0])
Out[110]: numpy.float64
In [111]: z=np.random.randint(0,4,size=(3,3)).astype('float')
In [112]: type(z[0][0])
Out[112]: numpy.float64
In [113]: np.shape(np.random.randint(0,4,size=(3,3)).astype('float'))
Out[113]: (3, 3)
In [114]: np.shape(x+y)
Out[114]: (3, 3)
In [115]: np.shape(x)
Out[115]: (3, 3)
In [116]: np.gradient(x+y, np.random.randint(0,4,size=(3,3)).astype('float'), axis=0)
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
<ipython-input-116-92d522988b0a> in <module>()
----> 1 np.gradient(x+y, np.random.randint(0,4,size=(3,3)).astype('float'), axis=0)
/home/chris/anaconda/lib/python2.7/site-packages/numpy/lib/function_base.pyc in gradient(f, *varargs, **kwargs)
1773 a.shape = b.shape = c.shape = shape
1774 # 1D equivalent -- out[1:-1] = a * f[:-2] + b * f[1:-1] + c * f[2:]
-> 1775 out[slice1] = a * f[slice2] + b * f[slice3] + c * f[slice4]
1776
1777 # Numerical differentiation: 1st order edges
ValueError: could not broadcast input array from shape (4,3) into shape (1,3) I'm with @evanmason really useful to be able to pass a dx/dy/dz as an array for geophysical datasets. I use it a lot with version numpy 1.11.2. And when running on real data I get the same error:
Here's an example (unzip and run on the attached):
Here's the output..
Here's the output using np 1.11.2
|
Sorry, yes I should have included that, here are dx and dy from pyproj, @eric-wieser
|
The problem in your Your first example doesn't have |
Ok, here's a simple repro: >>> x, y = np.meshgrid(np.arange(3), np.arange(4))
>>> np.gradient(x + y, x, y)
ValueError: distances must be either scalars or match the length of the corresponding dimension I don't think this ever did the right thing though. What is the output of the above for you on 1.10, @evanmason? |
Here's what I get, @eric-wieser
|
2d arrays would work, but in unpredictable and undocumented ways. This at least makes numpygh-9401 give a better error message.
2d arrays would work, but in unpredictable and undocumented ways. This at least makes numpygh-9401 give a better error message.
@evanmason: Sorry, I wasn't clear there, Can you run the code that I included in this answer, in your old version of numpy? |
@eric-wieser: Hi, here's what I get:
|
With np.gradient v1.11.0 it was possible to use 2d irregular dx and dy arguments, for example:
However with v.1.13.0 (and also in v.1.12.0) there is now an error:
ValueError: distances must be either scalars or match the length of the corresponding dimension
I know that gradient was recently updated #8446. I wonder if this functionality was overlooked, or expressly omitted. Either way it is useful when working with geophysical model data, and it would be nice to have it back again.
The text was updated successfully, but these errors were encountered: