On Wed, May 31, 2023 at 4:19 PM Charles R Harris <charlesr.har...@gmail.com> wrote:
> > > On Wed, May 31, 2023 at 8:05 AM Robert Kern <robert.k...@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/56BRFMN7LDV2VPRUVZGE7C2AIAGCGVBV/#OR25IGX4GRO5IK6GSGGPAH64IO466LAG [3] https://github.com/JuliaMath/openlibm/issues/212
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
