The reference manual has a floating point pitfalls section that has a warning against about how numba may produce slightly different results, for divergent functions.
I am working with agent based models, which are models which show emergent properties which are somewhat sensitive to initial conditions. So what exactly are the implications of this warning? Should I be worried about using numba?
Afaik, vanilla python/numpy implementation is also just some ways to represent and compute numbers, so have their own issues with floating point numbers. Now numba is a slightly different implementation. So in essence both are just doing the same thing, and one can’t be said to be more right than the other, correct?
This is a general problem with floating point computations and compilers, the warning in the reference manual is there just to raise awareness.
In Numba three fundamental things are different when compared to NumPy:
Numba has to work out the types of all the variables before it can compile anything, it may not always perfectly replicate NumPy. This may lead to e.g. a float64 where NumPy uses a float32.
Numba doesn’t always exactly replicate the algorithms NumPy uses, it may elect to do something equivalent but slightly different, and this can lead to small numerical differences.
Numba compiles and optimises your entire function, it’s not just dispatching work to a precompiled library as in the case of NumPy. Numba actually looks at your entire function and all the work in it and then optimises across all of that, including loops and a lot of function! As a result, this optimisation may lead to small numerical differences (for example, Numba could see two ufunc loops and elect to fuse them!).
Essentially, Numba just makes it more obvious that floating point behaves like floating point because there’s more cases where it’s apparent. As to correctness, there’s often a trade off, perhaps look at some different ways to compute the sum of a vector as an example, these two may be a good place to start:
Okay. So nothing to be worried about (more than any other library that does floating point computations) I suppose.
Thanks for your answer. I will be sure to report any discrepancies I come across.