#погрешности_округления — Public Fediverse posts

Об ошибках округления и способах борьбы с ними

Почему при сложениии одинаковых чисел в разном порядке получаются разные результаты? Как мининмизировать ошибки округления или избавиться от них совсем?

https://habr.com/ru/articles/922198/

#Вычисления #числа_с_плавающей_точкой #векторизация #параллелизм #погрешности_округления

Об ошибках округления и способах борьбы с ними

Почему при сложениии одинаковых чисел в разном порядке получаются разные результаты? Как мининмизировать ошибки округления или избавиться от них совсем?

https://habr.com/ru/articles/922198/

#Вычисления #числа_с_плавающей_точкой #векторизация #параллелизм #погрешности_округления

Об ошибках округления и способах борьбы с ними

Почему при сложениии одинаковых чисел в разном порядке получаются разные результаты? Как мининмизировать ошибки округления или избавиться от них совсем?

https://habr.com/ru/articles/922198/

#Вычисления #числа_с_плавающей_точкой #векторизация #параллелизм #погрешности_округления

[Перевод] Ни одна реализация элементарных функций не соответствует стандарту IEEE 754

Введённый в 1985 году стандарт IEEE-754 для чисел с плавающей запятой был предназначен для решения проблемы разнородности реализаций чисел с плавающей запятой, мешавших портируемости кода, а также для повышения стабильности между платформами. Он получил широкое применение и многократно пересматривался в течение прошедших лет. Если вы когда-нибудь работали с любыми вещественными числами в своих приложениях, то они, вероятно, отвечали этому стандарту. Моя работа в течение последнего года заключалась в анализе погрешности различных математических функций, накопления этой погрешности и способов её уменьшения при помощи различных программных паттернов. Одной из исследованных мной тем были базовые математические функции, используемые в функциях активации нейронных сетей, а также способы их аппроксимации для повышения производительности . В процессе работы нам пришлось столкнуться с противодействием со стороны людей, активно стремящихся к корректной реализации математических функций и к соответствию их стандартам, в частности, к соблюдению обеспечения корректности одной наименее значимой единицы измерения (unit in last place, ULP) для элементарных функций. Я был заинтересован в дальнейшей работе по аппроксимации этих функций, поэтому приступил к исследованию того, каким образом они гарантируют корректность, и если они корректны только на 1 ULP, то где располагаются ошибки в области определения функции. В процессе изучения я обнаружил, что ни одна из популярных математических библиотек, используемых во множестве сфер вычислений, на самом деле не выполняет корректное округление в соответствии с требованиями любой версии IEEE 754 после первой редакции 1985 года.

https://habr.com/ru/companies/ruvds/articles/881698/

#числа_с_плавающей_запятой #floating_point #ieee_754 #плавающая_запятая #плавающая_точка #погрешности_округления #fpu #ruvds_статьи

[Перевод] Укрощаем суммы с плавающей запятой

Допустим, у нас есть массив чисел с плавающей запятой, и мы хотим их суммировать. Можно наивно подумать, что их достаточно просто сложить, например, на Rust. Однако это запросто может привести к произвольно большой накопленной погрешности. Давайте проверим: naive_sum(&vec![1.0; 1_000_000]) = 1000000.0 naive_sum(&vec![1.0; 10_000_000]) = 10000000.0 naive_sum(&vec![1.0; 100_000_000]) = 16777216.0 naive_sum(&vec![1.0; 1_000_000_000]) = 16777216.0 Ой-ёй… Что произошло? Проблема в том .что следующее 32-битное число с плавающей запятой после 16777216 — это 16777218 . Так что при вычислении 16777216 + 1 , значение округляется до ближайшего числа с плавающей запятой, имеющей чётную мантиссу, то есть снова до 16777216 . Мы зашли в тупик. К счастью, есть более совершенные способы суммирования массива.

https://habr.com/ru/articles/819135/

#числа_с_плавающей_запятой #сложение #оптимизации #округление #погрешности_округления