Fix issues where +=, -= were being used on arrays with incompatible dtypes#2128
Conversation
| @@ -1,4 +1,4 @@ | |||
| # (C) British Crown Copyright 2015, Met Office | |||
| # (C) British Crown Copyright 2015-2016, Met Office | |||
There was a problem hiding this comment.
This needs to be formatted as 2015 - 2016 (note the spaces surrounding the dash -) as the current formatting is causing some of the license header tests to barf.
@djkirkham do you happen to have a reference for this assertion? |
|
@dkillick There's this section of the user guide. https://docs.scipy.org/doc/numpy-dev/numpy-user.pdf#page=13&zoom=auto,-266,577 |
lib/iris/experimental/regrid.py
Outdated
| if min_sx < 0 and min_tx >= 0: | ||
| indices = np.where(sx_points < 0) | ||
| sx_points[indices] += modulus | ||
| sx_points[indices] = sx_points[indices] + modulus |
There was a problem hiding this comment.
In the cases where this change fires we are now going to change (i.e. upcast) the dtype of sx_points, yes? Is this desirable behaviour, even if it is unavoidable?
Alternatively, was the previous behaviour even correct? Or was it upcasting anyway and just not raising an exception when it did so?
There was a problem hiding this comment.
Yes, it will upcast. Thanks for flagging this up; I hadn't put enough thought into whether the change could have undesirable consequences. As it happens, I think we're ok: sx_points is a temporary array used only by this method. It appears to be used to find a list of indices, so the dtype won't proliferate into other arrays.
Previously, in the case where the dtype of the sx_points was initially int and modulus was a float, it would simply round modulus down to the nearest integer, which is clearly wrong.
Disregard the above, I was talking rubbish.
|
Sorry this still isn't working... |
|
@djkirkham I agree that this fixes the errors, thanks! |
|
Can this be backported to v1.10.x? |
In Numpy1.10, you cannot use in-place operators on arrays where the RHS cannot be upcast to the LHS, e.g.,
int += float