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
In many @njit cases, we use fastmath=True. However, this might be bad when the input arguments and/or output results contain np.nan or np.inf (see Numba fastmath). In those cases, we should use more specific but slower fastmathflags like @njit(fastmath={"nsz", "arcp", "contract", "afn", "reassoc"})
We should spend some time to reassessing whether all of the fastmath specifications are accurate or if they need to be updated
The text was updated successfully, but these errors were encountered:
There is a nice article here on some of the differences in the fastmath flags. I wonder if it is possible/might be worth to go down a path where we assume that all njit functions must contain finite inputs/outputs. This will require some further preprocessing of the inputs AND post-processing of the outputs but it might be well worth the effort.
In many
@njit
cases, we usefastmath=True
. However, this might be bad when the input arguments and/or output results containnp.nan
ornp.inf
(see Numba fastmath). In those cases, we should use more specific but slowerfastmath
flags like@njit(fastmath={"nsz", "arcp", "contract", "afn", "reassoc"})
We should spend some time to reassessing whether all of the
fastmath
specifications are accurate or if they need to be updatedThe text was updated successfully, but these errors were encountered: