Hi Sebastian, I had a quick look at the PR and it looks like you re-implemented the sin-cos function using SIMD. I wonder how it compares with SLEEF (header only library, CPU-architecture agnostic SIMD implementation of transcendental functions with precision validation). SLEEF is close to the Intel SVML library in spirit but extended to multi-architecture (tested on PowerPC and ARM for example). This is just curiosity ...
Like Juan, I am afraid of this change since my code, which depends on numpy for sin/cos used for rotation is likely to see large change of behavior. Cheers, Jerome On Wed, 31 May 2023 07:55:34 +0200 Sebastian Berg <sebast...@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-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: jerome.kief...@esrf.fr -- Jérôme Kieffer tel +33 476 882 445 _______________________________________________ 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
