Как написать портативную арифметику с плавающей запятой в c++?

не-IEEE 754

как правило, вы не можете. Всегда есть компромисс между согласованностью и производительностью, и C++ передает Это вам.

для платформ, которые не имеют операций с плавающей запятой (например, встроенные и процессоры обработки сигналов), вы не можете использовать "родные" операции с плавающей запятой C++, по крайней мере, не переносимо. Хотя программный уровень был бы возможен, это, безусловно, невозможно для устройств такого типа.

для них можно использовать 16-битная или 32-битная арифметика с фиксированной точкой (но вы можете даже обнаружить, что long поддерживается только рудиментарно - и часто div очень дорого). Однако это будет намного медленнее, чем встроенная арифметика с фиксированной точкой, и станет болезненным после основных четырех операций.

Я не сталкивался с устройствами, которые поддерживают плавающую точку в другом формате, чем IEEE 754. По моему опыту, лучше всего надеяться на стандарт, потому что в противном случае вы обычно в конечном итоге построение алгоритмов и кода вокруг возможностей устройства. Когда sin(x) внезапно стоит в 1000 раз больше, вам лучше выбрать алгоритм, который в этом не нуждается.

IEEE 754 - согласованность

единственная непереносимость, которую я нашел здесь, - это когда вы ожидаете бит-идентичных результатов на разных платформах. Наибольшее влияние оказывает оптимизатор. Опять же, вы можете обменять точность и скорость на согласованность. У большинства компиляторов есть опция для этого-например, " плавающая точка согласованность " в Visual C++. Но обратите внимание, что это всегда точность дальше гарантии стандартные.

почему результаты становятся несовместимы? Во-первых, регистры FPU часто имеют более высокое разрешение, чем double (например, 80 бит), поэтому, пока генератор кода не сохраняет значение обратно, промежуточные значения хранятся с более высокой точностью.

во-вторых, эквивалентности, такие как a*(b+c) = a*b + a*c не являются точными из-за ограниченной точности. Однако оптимизатор, если это разрешено, может использовать их.

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

float

Это распространенное заблуждение, что операции float по своей сути быстрее, чем double. работа с большими массивами float быстрее, как правило,за счет меньшего количества пропусков кэша.

будьте осторожны с точностью поплавок. это может быть "достаточно хорошо" в течение длительного времени, но я часто видел, как это происходит быстрее, чем ожидалось. Float-based FFT может быть намного быстрее из-за поддержки SIMD, но генерировать заметные артефакты довольно рано для обработки звука.