Слишком не точно вычисляются библиотечные косинус и тангенс для переменных типа float

Если юзать использовать 4-байтовый float, для значений, близких к π/2 (90 град.) - ошибка уже в 4-м или даже 3-м знаке. У float гарантированная точность 6-7 значащих цифр, что никак не вяжется с ошибкой в 3 знаке.

Пример: cos(1.57) даёт: 0.000796274, правильное: 0.000796327.

Я знаю сколько подводных камней в вычислениях с плавающей точкой, все эти приколюхи с представлением, машинным эпсилоном и т. д., знаю что ошибка может накапливаться когда идёт несколько связанных вычислений. Но для простейших функций не ожидал такой погрешности. Тригонометрия вроде уже давно на уровне железа поддерживается. Почему тогда такая ошибка?

0

Сообщение от Geek Geekson для простейших функций не ожидал такой погрешности. ... Почему тогда такая ошибка?

Потому что косинус - не простейшая функция, а вычисление ряда. Ошибка накапливается.
Если не хотите использовать Double или Long Double, попробуйте поискать библиотеку математических функций, в которой реализованы алгоритмы расчётов с повышенной точностью.

0

Вот така [цензура] малята.

0

Погрешность ~0.00658%, вроде не очень много, но самому тоже интересно стало

0

А каким компилятором вы пользуетесь? у меня что-то не получается такой результат получить

Миниатюры

 

0

Сообщение от Geek Geekson У float гарантированная точность 6-7 значащих цифр, что никак не вяжется с ошибкой в 3 знаке. Пример: cos(1.57) даёт: 0.000796274, правильное: 0.000796327.

Я чот не понял, а чо тебе не нравится? 7 цифорр и есть, я проверил на куркулятере.



Если float не нравится, юзай double. Или тебя заставляют под дулами автоматов?

0

Сообщение от dmiteri у меня что-то не получается такой результат получить

У Вас 1.57 константа типа double.
А ТС имел ввиду:
или
кстати
cos(M_PI_2) дает 6.12323e-017
а cosf(M_PI_2) дает -4.37114e-008

0

Сообщение от Geek Geekson У float гарантированная точность 6-7 значащих цифр, что никак не вяжется с ошибкой в 3 знаке. Пример: cos(1.57) даёт: 0.000796274, правильное: 0.000796327.

Ошибка в седьмом знаке после точки. Третий знак это ноль.

0

Сообщение от Geek Geekson Но для простейших функций не ожидал такой погрешности

Я думаю дело вот в чем.
Ошибка в 7-м знаке после запятой. Не в "значащем 7-м", а именно в 7-м после запятой.
Видимо разработчики (не важно программной или аппаратной реализации) решили, что раз 7 знаков умещается во float - то и точноста расчетов надо взять "до 7 знака после запятой". В общем-то логично. (ну или даже до 6-го знака, т.к. гарантированно 6 знаков).
Задать "относительную" точность - не совсем понятно как в вычислениях ряда. Поэтому точность просто фиксированная.

0

Сообщение от zss кстати cos(M_PI_2) дает 6.12323e-017 а cosf(M_PI_2) дает -4.37114e-008

Это считай два нуля.

0

Сообщение от Geek Geekson Тригонометрия вроде уже давно на уровне железа поддерживается. Почему тогда такая ошибка?

Потому, что нужно читать доку по железу - доки по языку программирования недостаточно.
Берём интеловский талмуд Intel® 64 and IA-32 Architectures Software Developer’s Manual - Volume 2 - Instruction Set Reference.
Там для процессорной команды fcos чёрным по белому написано:

for accurate results it is safe to apply FCOS only to arguments reduced accurately in software, to a value smaller in absolute value than 3π/8.

3π/8=1.1781 - а ты суёшь 1.57.
Для синуса -

for accurate results it is safe to apply FSIN only to arguments reduced accurately in software, to a value smaller in absolute value than 3π/4.

Для тангенса -

for accurate results it is safe to apply FPTAN only to arguments reduced accurately in software, to a value smaller in absolute value than 3π/8.

Т.е. НИГДЕ нет гарантий точного вычисления на всей области значений double-аргумента трансцендентной команды. Проц сам делает/сделает редукцию "лишних" периодов у вычисляемой функции - но недостаточно. Надо процу помогать головой и руками - и в доке это напрямую сказано.
И всё равно трансцендентные процессорные команды будут вычислять приближённый результат. Слово accurate везде в цитатах выше - это не слово exact.

2

VTsaregorodtsev, спасибо. Открыл его и поискал там описание для double-варианта - и не нашёл вообще. Получается, в железе поддерживаются только 4-байтовые? И все операции с double считаются программно (через ряды например)? И тогда вопрос открыт насчёт точности для double. Но с карманным калькулятором, по крайней мере, там совпадает в 10 значащих цифрах.

Вообще у меня проц AMD, но они, как понял, тоже этому стандарту следуют?

Добавлено через 14 минут

Сообщение от Bans Ошибка в седьмом знаке после точки. Третий знак это ноль.

Тут имел в виду что ошибка в 3-4 значащей цифре, конечно. А не 3-м знаке после запятой. Нули слева значащими цифрами не являются.

0

Сообщение от Geek Geekson А не 3-м знаке после запятой. Нули слева значащими цифрами не являются.

Ты какие здесь нули имеешь в виду? Слева или справа от запятой?

0

Сообщение от Geek Geekson Открыл его и поискал там описание для double-варианта - и не нашёл вообще. Получается, в железе поддерживаются только 4-байтовые?

Продолжай курить мануалы по железу х86/х87, как для х32 - так и для х64.

Команды вычисления тригонометрии в х87 берут аргументом значение регистра st(0) на вершине fpu-стека. А этот и все остальные регистры там - 80битные (лонг дабл).
Т.е. у сишной функции cos() аргумент типа дабл всё равно будет загружен в fpu-регистр с расширением на бОльшую точность. У cosf() аргумент типа флоат - аналогично.
Возвращаемые значения - тоже все в лонг дабл, а флоатом/даблом они становятся только в момент выгрузки из регистра в ячейку памяти. Т.е. если запишешь что-то навроде z=cosf(x)*sinf(y) - то умножение произойдёт над лонг дабл-результатами функций, и к типу переменной z будет приведено только в момент записи значения в память.

Вышесказанное - если компилируем под х32, ибо под х64 соглашение о вызовах (calling convention) требует передачи плавучих аргументов функций не в fpu-регистрах, а в xmm-регистрах (для SSE/AVX-наборов команд), и возврата значений тоже через xmm-регистр. Поэтому вычисления тригонометрии в х64 могут реализовываться не через старую аппаратную х87-команду типа fsin/fcos/... (это требует пересылки полученного в xmm-регистре аргумента в память, загрузки его в fpu-регистр, и обратной пересылки результата тоже через память) - а библиотечным кодом непосредственно над значением в xmm-регистре.
И у плавучих типов данных в xmm-регистрах бывают только флоат и дабл - лонг дабла там нет.
Исходя из предыдущего предложения - один и тот же сишный/плюсовый код может при его компиляциях для х32+х87 и для х64+xmm давать затем разные результаты вычислений, ибо во втором случае нет возможности пользования более точным (лонг дабл) представлением данных на всех аппаратных/промежуточных вычислениях плавучей математики.

Сообщение от Geek Geekson Вообще у меня проц AMD, но они, как понял, тоже этому стандарту следуют?

Доки от/для АМД тоже в открытом доступе - бери и сравнивай
Просто в коллекции талмудов от АМД справочник по набору команд идёт не вторым томом (как у Интела) - а третьим, четвёртым и пятым.
Но сразу скажу, что там не так подробно, как у Интела.

2

Сообщение от Verevkin Ты какие здесь нули имеешь в виду? Слева или справа от запятой?

Все нули слева. Посмотри что такое значащие цифры.

0

Сообщение от Geek Geekson Пример: cos(1.57) даёт: 0.000796274, правильное: 0.000796327

Вот более правильное значение: cos(1.57)= 0.00079632671073332548540853364535418588 0175394345 (это к слову). Так что оба твоих значения неправильные. Кстати, откуда ты взял свое "правильное" значение?

И дело не регистрах процессора. Дело в алгоритме вычисления, в котором используются полиномы Чебышёва. Эта схема дает определенную погрешность. И что?

0

Сообщение от Catstail Так что оба твоих значения неправильные

Это почему? 0.000796327 - правильное в пределах 6 значащих цифр, обеспечиваемых точностью float. Последняя "7" - результат округления "67".

Сообщение от Catstail Кстати, откуда ты взял свое "правильное" значение?

Взял результат для double + проверил на калькуляторе. Для 6 значащих цифр этого по идее достаточно.

0

Geek Geekson, возможно вычисление sin(x-π/2) (или, даже, x-π/2) вместо cos(x) для значений x близких к π/2 будет точнее...

0

Сообщение от Geek Geekson проверил на калькуляторе.

-

0

Catstail, за неимением вагона времени. По крайней мере значение с разных калькуляторов и с типа double совпадает в пределах отображаемых цифр, это уже о чём-то говорит. И да, критикуя - предлагай.

0