Skip to content

BUG: The "default floatingpoint error setting" logic can misfire, especially with threads #19006

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
seberg opened this issue May 13, 2021 · 1 comment · Fixed by #23936
Closed

Comments

@seberg
Copy link
Member

seberg commented May 13, 2021

The lines at

if ((errmask != UFUNC_ERR_DEFAULT) || (bufsize != NPY_BUFSIZE)
|| (PyTuple_GET_ITEM(errobj, 1) != Py_None)) {
PyUFunc_NUM_NODEFAULTS += 1;
}
else if (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)
@seberg
Copy link
Member Author

seberg commented 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)...

@seberg 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 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant