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. On Wed, May 31, 2023 at 1:59 AM Sebastian Berg <sebastian@sipsolutions.net> wrote:
Hi all,
there was recently a PR to NumPy to improve the performance of sin/cos on most platforms (on my laptop it seems to be about 5x on simple inputs). This changes the error bounds on platforms that were not previously accelerated (most users):
https://github.com/numpy/numpy/pull/23399
The new error is <4 ULP similar to what it was before, but only on high end Intel CPUs which not users would have noticed. And unfortunately, it is a bit unclear whether this is too disruptive or not.
The main surprise is probably that the range of both does not include 1 (and -1) exactly with this and quite a lot of downstream packages noticed this and needed test adaptions.
Now, most of these are harmless: users shouldn't expect exact results from floating point math and test tolerances need adjustment. OTOH, sin/cos are practically 1/-1 on a wide range of inputs (they are basically constant) so it is surprising that they deviate from it and never reach 1/-1 exactly.
Since quite a few downstream libs notice this and NumPy users cannot explicitly opt-in to a different performance/precision trade-off. The question is how everyone feels about it being better to revert for now and hope for a better one?
I doubt we can decide on a very clear cut yes/no, but I am very interested what everyone thinks whether this precision trade-off is too surprising to users?
Cheers,
Sebastian
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: robert.kern@gmail.com
-- Robert Kern