On Wed, May 31, 2023 at 4:19 PM Charles R Harris <charlesr.harris@gmail.com> wrote:
On Wed, May 31, 2023 at 8:05 AM Robert Kern <robert.kern@gmail.com> wrote:
I would much, much rather have the special functions in the `np.*` namespace be more accurate than fast on all platforms. These would not have been on my list for general purpose speed optimization. How much time is actually spent inside sin/cos even in a trig-heavy numpy program? And most numpy programs aren't trig-heavy, but the precision cost would be paid and noticeable even for those programs. I would want fast-and-inaccurate functions to be strictly opt-in for those times that they really paid off. Probably by providing them in their own module or package rather than a runtime switch, because it's probably only a *part* of my program that needs that kind of speed and can afford that precision loss while there will be other parts that need the precision.
I think that would be a good policy going forward.
There's a little more to it than "precise and slow good", "fast == less accurate == bad". We've touched on this when SVML got merged (e.g., [1]) and with other SIMD code, e.g. in the "Floating point precision expectations in NumPy" thread [2]. Even libm doesn't guarantee the best possible result of <0.5 ULP max error, and there are also considerations like whether any numerical errors are normally distributed around the exact mathematical answer or not (see, e.g., [3]). It seems fairly clear that with this recent change, the feeling is that the tradeoff is bad and that too much accuracy was lost, for not enough real-world gain. However, we now had several years worth of performance work with few complaints about accuracy issues. So I wouldn't throw out the baby with the bath water now and say that we always want the best accuracy only. It seems to me like we need a better methodology for evaluating changes. Contributors have been pretty careful, but looking back at SIMD PRs, there were usually detailed benchmarks but not always detailed accuracy impact evaluations. Cheers, Ralf [1] https://github.com/numpy/numpy/pull/19478#issuecomment-883748183 [2] https://mail.python.org/archives/list/numpy-discussion@python.org/thread/56B... [3] https://github.com/JuliaMath/openlibm/issues/212