В разрабатываемую Glibc 2.41 добавили cospi(), sinpi() и tanpi().

grep "PI" /usr/include/math.h
# define M_PI           3.14159265358979323846  /* pi */
# define M_PI_2         1.57079632679489661923  /* pi/2 */
# define M_PI_4         0.78539816339744830962  /* pi/4 */
# define M_1_PI         0.31830988618379067154  /* 1/pi */
# define M_2_PI         0.63661977236758134308  /* 2/pi */
# define M_2_SQRTPI     1.12837916709551257390  /* 2/sqrt(pi) */
# define M_PIf          3.14159265358979323846f /* pi */
# define M_PI_2f        1.57079632679489661923f /* pi/2 */
# define M_PI_4f        0.78539816339744830962f /* pi/4 */
# define M_1_PIf        0.31830988618379067154f /* 1/pi */
# define M_2_PIf        0.63661977236758134308f /* 2/pi */
# define M_2_SQRTPIf    1.12837916709551257390f /* 2/sqrt(pi) */
[...]

Есть какая-то причина использовать новые функции?

повышение точности для произвольного x? но я не знаю как оно достигается.

Ради интереса я посмотрел, как они делают, и не увидел ничего особенного по поводу точности.

Вот, непример, код для косинуса: https://sourceware.org/git/?p=glibc.git;a=blob;f=math/s_cospi_template.c;h=2eb907973dd40f25436782db1849eb6fd1bcc522;hb=0ae0af68d8fa3bf6cbe1e4f1de5929ff71de67b3

Тут только крайние случаи для x = 0, 1/2 и бесконечности, далее значение x заворачивается в кольцо и вызывается не-pi функция как возврат. Никаких оптимизаций или увеличения точности за пределами крайних случаев нет. Сугубо производится сокращение boilerplate для функции, про которую в четырёх случаях из пяти даже не вспомнят.

Печально. Я ожидал, что экономия одного умножения всё-таки будет

добавили cospi(), sinpi() и tanpi().

Это функции военного времени :)

… tanpi(x) возвращает tan(π*x).

Это еще, может, и добавит точности при x = 1/2 + n + epsilon (n=0,+-1,+-2,…). А cospi(), sinpi() зачем?

Подозреваю что заворачивание в кольцо x до умножения на пи само по себе точнее чем после. Потому как оно целочисленное, а находить остаток от деления на иррациональное число - явная потеря точности.

Потому как оно целочисленное

Мб наоборот :)

Но вообще да, чисто технически в этом толк есть. Однако, если хочется либо быстрее, либо точнее, то нужно будет всё равно самому писать.

Главное чтобы не удаляли ничего.

Подозреваю что заворачивание в кольцо x до умножения на пи само по себе точнее чем после.

Все равно перед вызовом делить угол на pi.

В итоге непонятно нахрена это. Только код glibc раздувается и ломается совместимость.

Кстати, решил потестить что получается через классические функции. Получилось это:

x = 0.000000, sin(x) = 0.000000, cos(x) = 1.000000, tan(x) = 0.000000
x = 1.570796, sin(x) = 1.000000, cos(x) = 0.000000, tan(x) = 16331239353195370.000000
x = 3.141593, sin(x) = 0.000000, cos(x) = -1.000000, tan(x) = -0.000000
x = 4.712389, sin(x) = -1.000000, cos(x) = -0.000000, tan(x) = 5443746451065123.000000
x = 6.283185, sin(x) = -0.000000, cos(x) = 1.000000, tan(x) = -0.000000

В итоге непонятно нахрена это. Только код glibc раздувается и ломается совместимость.

в glibc понятно почему - вслед за стандартом. А вот нахрена они в стандарте, вот то загадка..

x = 1.570796

Не пойдет. Надо полный воспроизводимый код. Например, double x = M_PI/2; …

IEEE 754-2019, казалось бы, причем тут стандарт на числа?

Clause 9 in the standard recommends additional mathematical operations that language standards should define

IEEE 754-2019
9.2 new tanPi, aSinPi, and aCosPi operations

Причины: Стандартизация поведения подобных функций, и приводятся аргументы которые говорят что они могут быть быстрее, но у разработчиков glibc пока руки не дошли.

Непраавильно ты, дядя Федор, тангенс pi/2 вычисляешь.

Есть какая-то причина использовать новые функции?

эти функции указаны в стандарте IEEE 754 (и одинаковом с ним ISO/IEC 60559) как рекомендованные к реализации, вот их и реализовали. Никаких других особых причин, судя по всему, нет.

Не надо ничего делить, эти функции для того чтоб ты мог хранить углы не в радианах а в процентах от пи. Например, прямой угол будет 0.5, которое, в отличие от pi/2, можно хранить без потерь точности.

Не надо ничего делить, эти функции для того чтоб ты мог хранить углы не в радианах а в процентах от пи.

Это правильно.

Но есть куча отлаженных библиотек, которые по входным данным возвращают углы в радианах. Их придется тоже переписать.

// Или переписать все в представлении SU(2)/Z2 вместо привычной SO(3). Проблем с делением на cos(n*pi + pi/2 + epsilon) будет меньше.

ЭЭЭЭ это поветрие от rust такое дробную математику везде пихать.

… это поветрие от rust такое дробную математику везде пихать.

gnu mpfr задолго до rust сделали.

gnu mpfr для математики кому нужно тот и подключит, Glibc существует для работы с ос и поддержка дробных чисел в таком ракурсе не обязательна и может даже не реализована в процессоре. Проблема rust в ядре как раз и состояла, что ядро запускается на системе с ЦПУ без поддержки float, double (например некоторые arm).

Проблема rust в ядре как раз и состояла, что ядро запускается на системе с ЦПУ без поддержки float, double (например некоторые arm).

Хмм, здесь вроде как про прикладную математику, которую никому сейчас в голову не придет считать без аппаратной поддержки операций с float/double.

P.S.

Glibc существует для работы с ос и поддержка дробных чисел в таком ракурсе не обязательна и может даже не реализована в процессоре. Проблема rust в ядре …

При чем glibc к ядру?

Чот совсем перестал понимать за этот ваш линакс. Надо 150 и спать.