Repository navigation
BUG: The "default floatingpoint error setting" logic can misfire, especially with threads #19006
Description
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:
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)
Activity
seberg commentedon May 13, 2021
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)...
[-]BUG: The default ufunc-error skipping doesn't seem correctly threaded[/-][+]BUG: The "default floatingpoint error setting" logic can misfire, especially with threads [/+]