On 31 May 2023, at 16:32, numpy-discussion-request@python.org<mailto:numpy-discussion-request@python.org> wrote: 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 If I can throw my 2cents in, my feeling is that most user will not notice neither the decrease in accuracy, nor the increase in speed. (I failed to mention, I'm an engineer.... so a few ULPs are almost nothing for me; unless I have to solve a very ILL conditioned problem, but then I do not blame numpy, but myself for formulating such a bad model ;-) The only real problem is for code that relies on these assumptions: assert np.sin(np.pi/2) == -np.cos(np.pi) == 1 which will fail in numpy==1.25.rc0 but should hold true for numpy~=1.24.3, at least on most runtime environments. I do not have strong feelings on this issue: in an ideal world code should have unit-testing modules and assertion scattered here and there in order to make all implicit assumptions explicit. Adapting to the new routines should be fairly simple. Of course we do not live in an ideal world and there will definitely be a number of users that will experience hard to debug failures linked to this new trig routines. But again I prefer to remain neutral. Stefano