Standardised warnings & agnostic warning handling à la np.errstate
?
#849
Replies: 3 comments 3 replies
-
It's something Dask could fix, but also I've always considered these particular "empty slice" warnings a design problem in NumPy. The warnings are quite annoying in a lot of contexts - if the correct (or agreed-upon) return value for |
Beta Was this translation helpful? Give feedback.
-
FWIW, I don't mind changing it in NumPy. And we probably just should! The question may be for any function where I think we return |
Beta Was this translation helpful? Give feedback.
-
Actually, I think this isn't a problem for |
Beta Was this translation helpful? Give feedback.
-
https://data-apis.org/array-api/2023.12/design_topics/exceptions.html#exceptions hints that some of what arises here is out of scope for the standard, but opening this discussion to give concrete examples of some problems I have hit.
Working in the array API standard ecosystem I have bumped into two complications related to warnings.
Firstly, there is a long-standing Dask issue opened by @shoyer regarding NumPy warnings escaping from warning context managers when Dask arrays delay computation - dask/dask#3245.
Arguably this is a Dask bug and is irrelevant to the standard, but nevertheless it is causing errors when trying to make SciPy work with all standard(-ish) libraries. Ideally, for SciPy, there would be an array-agnostic way to capture that we want to 'ignore warnings about divide by 0 in this section of code' regardless of the implementation of the underlying library
xp
.Related to the above problem - data-apis/array-api-extra#14 proposes finding a public home for SciPy's private helper
_lazywhere
in array-api-extra. The helper is written to be array-agnostic, apart from a use ofwith np.errstate(invalid='ignore'):
. Functions in array-api-extra are strictly array-agnostic, depending only on the standard.This isn't the end of the world for SciPy, as we could instead just wrap
xpx.lazywhere
in a lightnp.errstate
context manager. But this is obviously less ideal than being able to maintain the granularity of the context manager. And complications could arise if other implementations to NumPy start throwing their own warnings too.Beta Was this translation helpful? Give feedback.
All reactions