-
Notifications
You must be signed in to change notification settings - Fork 283
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
Fix master np113 #2616
Fix master np113 #2616
Changes from 4 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -239,6 +239,24 @@ def _xy_range(cube, mode=None): | |
return (x_range, y_range) | ||
|
||
|
||
def _meshgrid(x, y): | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think on balance I'd prefer this to live in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed. Is this not behaviour that would be useful to have consistent across the entire package? Perhaps if util were made a sub-package, then it would no longer be such a difficult call to add add additional 'utilities' for fear of further discontinuity: iris.util.ndarray.meshgrid In ANTS we have the following structure, which has served us very well: ants.utils.ndarray
ants.utils.coord
ants.utils.cube There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not looked at the details, but numpy/numpy#5302 refers. |
||
""" | ||
@numpy v1.13, the dtype of each output nD coordinate is the same as its | ||
associated input 1D coordinate. This is not the case prior to numpy v1.13, | ||
where the output dtype is cast up to its highest resolution, regardlessly. | ||
|
||
This convenience function ensures consistent meshgrid behaviour across | ||
numpy versions. | ||
|
||
""" | ||
mx, my = np.meshgrid(x, y) | ||
if mx.dtype != x.dtype: | ||
mx = mx.astype(x.dtype) | ||
if my.dtype != y.dtype: | ||
my = my.astype(y.dtype) | ||
return mx, my | ||
|
||
|
||
def get_xy_grids(cube): | ||
""" | ||
Return 2D X and Y points for a given cube. | ||
|
@@ -259,7 +277,7 @@ def get_xy_grids(cube): | |
|
||
if x.ndim == y.ndim == 1: | ||
# Convert to 2D. | ||
x, y = np.meshgrid(x, y) | ||
x, y = _meshgrid(x, y) | ||
elif x.ndim == y.ndim == 2: | ||
# They are already in the correct shape. | ||
pass | ||
|
@@ -284,7 +302,7 @@ def get_xy_contiguous_bounded_grids(cube): | |
|
||
x = x_coord.contiguous_bounds() | ||
y = y_coord.contiguous_bounds() | ||
x, y = np.meshgrid(x, y) | ||
x, y = _meshgrid(x, y) | ||
|
||
return (x, y) | ||
|
||
|
@@ -608,7 +626,7 @@ def project(cube, target_proj, nx=None, ny=None): | |
source_x = lon_coord.points | ||
source_y = lat_coord.points | ||
if source_x.ndim != 2 or source_y.ndim != 2: | ||
source_x, source_y = np.meshgrid(source_x, source_y) | ||
source_x, source_y = _meshgrid(source_x, source_y) | ||
|
||
# Calculate target grid | ||
target_cs = None | ||
|
@@ -1062,7 +1080,7 @@ def rotate_winds(u_cube, v_cube, target_cs): | |
|
||
# Convert points to 2D, if not already, and determine dims. | ||
if x.ndim == y.ndim == 1: | ||
x, y = np.meshgrid(x, y) | ||
x, y = _meshgrid(x, y) | ||
dims = (y_dims[0], x_dims[0]) | ||
else: | ||
dims = x_dims | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1 @@ | ||
{"std": 3.7195861803241614, "min": -5.593200206756592, "max": 8.72130012512207, "shape": [93, 75], "masked": false, "mean": 1.6348200228305594} | ||
{"std": 3.7195863723754883, "min": -5.5932002067565918, "max": 8.7213001251220703, "shape": [93, 75], "masked": false, "mean": 1.6348202228546143} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It might have been "nicer" here to reduce the tolerance on the test for when it happens again (!). Just a suggestion -- skip if you don't want. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @pp-mo I'm really against fudging the tolerances. We took that step previously with testing and it ultimately lead to a bad place, particularly with graphical testing. So, I'd rather not take that option, unless you consider it unwise. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't consider it fudging as long as the value used remains appropriate. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you maybe explain exactly what this is about, just for future reference ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be fair, this doesn't belong in this PR, so I'll pull it ... but the
__version__
should bePEP440
.I'll save that for another day and another PR 👍