Repository navigation
MAINT,ENH: Use non-error functions isless, isgreater, etc. #19398
Description
The functions isless, and friends (see https://en.cppreference.com/w/c/numeric/math/isless) are C99 standardized and should be equivalent to the normal math operators but not set floating point exceptions. I expect that using these macros would remove almost all of the places where we currently set npy_clear_floatstatus_barrier().
That would both slightly speed things up (at least if errors did occur npy_clear_floatstatus_barrier is pretty slow), and just be slightly more correct not to worry set the flags in the first place.
In the long-run, I am also thinking of chaining (e.g. by numexpr), where a call to npy_clear_floatstatus_barrier could silence floating point warnings, if the ufuncs are chained in lowlevel C.
EDIT: https://www.gnu.org/software/libc/manual/html_node/FP-Comparison-Functions.html is probably a nice reference
Activity
seberg commentedon Jul 22, 2021
I had done this in gh-19476, but it turns out that:
≤19is incapable to optimizeisnan,isfinite,isless, etc. (because they are defined inmath.h), making them extremely slow in general (maybe global, link-time, optimization can safe that a bit, but I am not sure. They are compiled into a function call, instead the single CPU instruction they should be).<10.0seems to not honor the request properly with optimization at least.So: We can probably use these functions as in gh-19316, where Mac breaks correctness anyway and the MSVC slowdown is likely acceptable, but unfortunately probably not yet(?) for things like maximum/minimum.