Корректная округлённость на практике нужна, в основном, для воспроизводимости результата на другой платформе. Библиотека с интервальной арифметикой не гарантирует, что интервал на двух разных платформах будет одинаков.
В компиляторе Intel есть ключи, которые позволяют управлять точностью трансцендентных функций (типа -fimf-accuracy-bits), и по умолчанию стоит -fimf-precision=medium, т.е. не самая точная из имеющихся.
Как правило, разница в скорости исполнения между 1ulp функцией и корректно округлённой функцией — 2-4 раза. А ведь тут мы говорим, про [почти] один распоследний бит ответа, который никто не заметит.
Справедливости ради, хотелось бы сказать, что по поводу log2p1(), popcount() и прочих функций из этой группы была большущая дискуссия на последнем собрании C++ комитета в Белфасте. Внутри коитета аудитория существенно разделилась. В силу отсутствия консенсуса было принято волевое решение. И если мне не изменяет память, log2p1 таки переименовали в bit_width.
В частности поэтому в IEEE 754 2008 года добавили десятичную арифметику. Существую даже железки которые поддерживают десятичную арифметику с плавающей точкой на уровне инструкций.
80 бит только тогда, когда вас совершенно не интересует производительность решения, но есть ощущение, что ещё чуть-чуть и хватит точности. По большому счёту, в 2017 году можно смело рекомендовать не смотреть на 80 бит никогда, если только это не жуткое легаси.
Если даблов не хватает, а производительность не интересует, то есть библитеки для вычислений произвольной точность, типа GNU MPFR.
Если даблов не хватает, но производительность важна — меняйте алгоритм.
Какой-то субурный набор наблюдений про числа с плавающей точкой.
Самые большие относительные ошибки внезапно лезут не при сложении, а при вычитании близких значений.
3.1415 — 3.1414 -> В результате этой операции в мантиссе младшие 4 знака заполнены нулями, т.е. мусором.
На импортном языке называется catastrophic cancellation.
В общем и среднем по архитектурам, можно ожидать, что векторизованный код должен отличатся float vs. double по производительности в 2x для арифметических операций ±/*. С делилкой уже не так, с корнями, экспонентами и прочими синусами разрыв больше.
В выводах написано — много складываете, то складывайте в даблах. А что делать, если я умножаю много — float нормально?
Наиболее существенная ценность в цафиксированном стиле кодирования — упрощение поддержки кода. Боль поддержки кода очень сложно передать в университете. Осознание приходит с опытом (о чём и статья).
Как правило, разница в скорости исполнения между 1ulp функцией и корректно округлённой функцией — 2-4 раза. А ведь тут мы говорим, про [почти] один распоследний бит ответа, который никто не заметит.
Если даблов не хватает, а производительность не интересует, то есть библитеки для вычислений произвольной точность, типа GNU MPFR.
Если даблов не хватает, но производительность важна — меняйте алгоритм.
Самые большие относительные ошибки внезапно лезут не при сложении, а при вычитании близких значений.
3.1415 — 3.1414 -> В результате этой операции в мантиссе младшие 4 знака заполнены нулями, т.е. мусором.
На импортном языке называется catastrophic cancellation.
В общем и среднем по архитектурам, можно ожидать, что векторизованный код должен отличатся float vs. double по производительности в 2x для арифметических операций ±/*. С делилкой уже не так, с корнями, экспонентами и прочими синусами разрыв больше.
В выводах написано — много складываете, то складывайте в даблах. А что делать, если я умножаю много — float нормально?