Check fastmath=True

[seanlaw]

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 fastmath 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 updated

[seanlaw]

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.

[seanlaw]

@NimaSarajpoor Did you actually spend time checking each fastmath flag to ensure that it has the right/appropriate flag in PR #1048 or does this work still need to happen?

[NimaSarajpoor]

@seanlaw
I did not. So, I think we should keep this issue open.

IIRC, in #1025, we had some discussion around a code that finds caller(s) of njit function. We can add a function in ./fastmath.py that raises an error if it finds a njit function whose fastmath flag is not a subset of the fastmath flag of its caller njit function(s). In addition, any njit function with fastmath=True needs to be checked [manually] to make sure it does not take an input that contains np.inf / np.nan.

What are your thought?