You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
if ((errmask!=UFUNC_ERR_DEFAULT) || (bufsize!=NPY_BUFSIZE)
|| (PyTuple_GET_ITEM(errobj, 1) !=Py_None)) {
PyUFunc_NUM_NODEFAULTS+=1;
}
elseif (PyUFunc_NUM_NODEFAULTS>0) {
PyUFunc_NUM_NODEFAULTS-=1;
}
are wrong. Before getting that error, the previous error may already have been default (or may not have been set at all). In that case, a "num-defaults" is decremented. This logic really needs to check the previous state more than the current, I think.
This can be triggered using only one thread, even with np.errstate:
arr = np.arange(3)
with np.errstate(all="raise"):
with np.errstate("all="ignore"):
pass
# gives the correct value, but uses the lookup (using threads, the opposite will be possible
# -- although not super likely -- using the "defaults" even though the defaults are not set.
np.add(arr, arr)
The text was updated successfully, but these errors were encountered:
If we ever had warnings surface even though the errorstate should have been different, I will blame this issue, but I can't actually remember any concrete report.
EDIT: Thought it might be a good (quite small) project, but now I am unsure how easy it is to get right with threading (or if it is even possible)...
seberg
changed the title
BUG: The default ufunc-error skipping doesn't seem correctly threaded
BUG: The "default floatingpoint error setting" logic can misfire, especially with threads
May 13, 2021
seberg
added
sprintable
Issue fits the time-frame and setting of a sprint
Project
Possible project, may require specific skills and long commitment
and removed
sprintable
Issue fits the time-frame and setting of a sprint
Project
Possible project, may require specific skills and long commitment
labels
May 13, 2021
The lines at
numpy/numpy/core/src/umath/extobj.c
Lines 40 to 46 in 018fb37
are wrong. Before getting that error, the previous error may already have been default (or may not have been set at all). In that case, a "num-defaults" is decremented. This logic really needs to check the previous state more than the current, I think.
This can be triggered using only one thread, even with
np.errstate
:The text was updated successfully, but these errors were encountered: