Glibc 2.41 Adds C23's sinpi / cospi / tanpi Functions

[phoronix]

Phoronix: Glibc 2.41 Adds C23's sinpi / cospi / tanpi Functions

Ahead of the GNU C Library "glibc" 2.41 release due out around early February, more C23 features are being finished up. The latest crossing the finish line is support for C23's sinpi, cospi, and tanpi trigonometric functions...

https://www.phoronix.com/news/Glibc-2.41-More-C23

[hotaru]

DNUS?

[ms178]

What about the Clang support? Is this work put on hold? The https://github.com/bminor/glibc/tree/azanella/clang branch has been quite for eight months.

[Weasel]

These should have been the default, with normal sin/cos inline functions or macros that simply pre-multiply by inverse of pi.

[jabl]

These should have been the default, with normal sin/cos inline functions or macros that simply pre-multiply by inverse of pi.

We can quibble whether these should have been the default back in the day instead of the usual ones taking an angle in radians, but no, you can absolutely not just multiply/divide with the usual floating point approximation of pi to go from one to the other as long as you care at all about accuracy. See for instance the famous article by Ng from 30+ years ago, for which a copy seems to be online at https://www.csee.umbc.edu/~phatak/64...gReduction.pdf

[willmore]

sinpi(x)=sin(x*pi) That's nice, but why not 2*pi? Wouldn't that be much more natural? Now we just need a fractional only floating point format.

[Weasel]

We can quibble whether these should have been the default back in the day instead of the usual ones taking an angle in radians, but no, you can absolutely not just multiply/divide with the usual floating point approximation of pi to go from one to the other as long as you care at all about accuracy. See for instance the famous article by Ng from 30+ years ago, for which a copy seems to be online at https://www.csee.umbc.edu/~phatak/64...gReduction.pdf

The thing is that the variants that use radians almost have no use in practice (if you simply redesign the scaling in whatever you use, and 1.0 is much simpler than Pi and exact to represent in binary and are also faster), except to deal with user interface/display stuff when the user is expecting radians… which doesn't require accuracy as the underlying calculation can still be done with sinpi/cospi.