Numpy made a few changes to their API with version 2.0. This PR addresses the places where they impact GalSim code.
np.array(a, copy=False) is now an error if a copy is required for the dtype. Using copy=None now does the equivalent to what copy=False used to do. But in most cases, it's better to just use np.asarray(a), which is equivalent in both versions.
There is one case where we have a more complicated decision about whether to copy, so in that case we need to use an explicit version check to get the right kwarg.
They changed the implicit dtype conversion for values in e.g. += and similar operations. For GalSim purposes, this mostly just required changing test expectations. E.g. using Image(..., dtype=float) when we want to test accuracy at double precision.
One other gotcha is that Python int cannot be implicitly assigned to np.uint types. This feels like a bug to me, since np.int types do work. Just not a regular Python int. cf. numpy issue https://github.com/numpy/numpy/issues/26483 However, it is likely that in most cases where this would show up in user code, it is likely some kind of user error. So I think it's best to not work around it, but rather just let the exception be raised. We explicitly avoid it by using np.int types in tests where it would otherwise be a problem.
Related to the above, Image.__neg__ now uses np.int64(-1), rather than just -1, so it will continue to work the same way it used to for unsigned dtypes.
Finally, np.trapz is deprecated. The new name is np.trapezoid. We mostly don't use it, since our own implementation is faster, but there were a few places in the tests that needed to be updated.
Numpy made a few changes to their API with version 2.0. This PR addresses the places where they impact GalSim code.
copy=None
now does the equivalent to whatcopy=False
used to do. But in most cases, it's better to just usenp.asarray(a)
, which is equivalent in both versions.Image(..., dtype=float)
when we want to test accuracy at double precision.Image.__neg__
now uses np.int64(-1), rather than just -1, so it will continue to work the same way it used to for unsigned dtypes.np.trapezoid
. We mostly don't use it, since our own implementation is faster, but there were a few places in the tests that needed to be updated.