I am not in favor of reverting this change. We already accounted for this in Matplotlib ( https://github.com/matplotlib/matplotlib/issues/25789 and https://github.com/matplotlib/matplotlib/pull/25813). It was not actually that disruptive and mostly identified tests that were too brittle to begin with. My understanding is that a majority of the impact is not that the results are inaccurate, it is that they are differently inaccurate than they used to be. If this is going to be reverted I think the burden should be on those who want the reversion to demonstrate that the different results actually matter. Tom On Wed, May 31, 2023 at 10:11 AM Matthew Brett <matthew.brett@gmail.com> wrote:
On Wed, May 31, 2023 at 3:04 PM 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.
What Robert said :)
But I still think the ideal would be the runtime option, maybe via the proposed context manager, for them as do need it, or want to try it out.
Cheers,
Matthew _______________________________________________ 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: tcaswell@gmail.com
-- Thomas Caswell tcaswell@gmail.com