硬件设计师的视角

我认为，既然我设计并构建了浮点硬件，我就应该添加一个硬件设计师的视角。了解错误的来源可能有助于了解软件中发生的情况，最终，我希望这有助于解释为什么浮点错误会发生并似乎会随着时间累积的原因。

1.概述

从工程角度来看，大多数浮点运算都会有一些误差，因为进行浮点运算的硬件只需要在最后一个位置的误差小于一个单位的一半。因此，许多硬件将停止在一个精度上，该精度只需要在单个操作的最后位置产生小于一个单位的一半的误差，这在浮点除法中尤其有问题。什么构成一个操作取决于该单元需要多少个操作数。大多数情况下，它是两个，但有些单位需要3个或更多操作数。因此，不能保证重复操作会导致期望的错误，因为错误会随着时间的推移而增加。

2.标准

大多数处理器遵循IEEE-754标准，但有些处理器使用非规范化或不同的标准例如，IEEE-754中存在一种非规范化模式，该模式允许以精度为代价表示非常小的浮点数。然而，下面将介绍IEEE-754的标准化模式，这是典型的操作模式。

在IEEE-754标准中，硬件设计者可以使用误差/ε的任何值，只要它在最后一个位置小于一个单位的一半，并且一次操作的结果只需要在最后一位小于一个单元的一半。这解释了为什么当重复操作时，错误会增加。对于IEEE-754双精度，这是第54位，因为53位用于表示浮点数的数字部分（标准化），也称为尾数（例如5.3e5中的5.3）。下一节将更详细地介绍各种浮点操作的硬件错误原因。

3.除法舍入误差的原因

浮点除法误差的主要原因是用于计算商的除法算法。大多数计算机系统使用逆函数的乘法来计算除法，主要是Z=X/Y，Z=X*（1/Y）。迭代地计算除法，即每个周期计算商的一些比特，直到达到所需的精度，对于IEEE-754来说，这是最后一位误差小于一个单位的任何值。Y（1/Y）的倒数表在慢除法中被称为商选择表（QST），商选择表的位大小通常是基数的宽度，或每次迭代中计算的商的位数，加上几个保护位。对于IEEE-754标准，双精度（64位），它将是除法器基数的大小，加上几个保护位k，其中k>=2。因此，例如，一次计算2位商（基数4）的除法器的典型商选择表将是2+2=4位（加上几个可选位）。

3.1除法舍入误差：倒数近似

商选择表中的倒数取决于除法：慢除法如SRT除法，或快除法如Goldschmidt除法；根据除法算法修改每个条目，以尝试产生最小的可能误差。然而，在任何情况下，所有的倒数都是实际倒数的近似值，并引入了一些误差因素。慢除法和快除法都迭代地计算商，即每一步计算商的一些位数，然后从被除数中减去结果，除法器重复这些步骤，直到误差小于最后一个单位的一半。慢除法计算每一步的商的固定位数，通常构建成本较低，而快除法计算每步的位数可变，构建成本通常较高。除法中最重要的部分是，它们大多依赖于通过倒数的近似值进行重复乘法，因此容易出错。

4.其他操作中的舍入错误：截断

所有操作中舍入误差的另一个原因是IEEE-754允许的最终答案的不同截断模式。有截断、向零舍入、向最接近（默认）舍入、向下舍入和向上舍入。所有方法都会在单个操作的最后位置引入小于一个单位的误差元素。随着时间的推移和重复操作，截断也会累积地增加结果误差。这种截断误差在涉及某种形式的重复乘法的求幂运算中尤其有问题。

5.重复操作

由于执行浮点计算的硬件只需要在单个操作的最后一个位置产生误差小于一个单位的一半的结果，因此如果不注意，误差将随着重复操作而增加。这就是为什么在需要有界误差的计算中，数学家使用诸如在IEEE-754的最后一位使用舍入到最接近的偶数位的方法，因为随着时间的推移，误差更可能相互抵消，而区间算术结合了IEEE754舍入模式的变化来预测舍入误差，并对其进行校正。由于与其他舍入模式相比，其相对误差较低，因此舍入到最近的偶数位（最后一位）是IEEE-754的默认舍入模式。

请注意，默认舍入模式（舍入到最后一位最接近的偶数位）保证一次操作的误差小于最后一位单位的一半。仅使用截断、向上舍入和向下舍入可能会导致误差大于最后一位一个单位的一半，但小于最后一位的一个单位，因此不建议使用这些模式，除非它们用于区间算术。

6.总结

简而言之，浮点运算中出现错误的根本原因是硬件中的截断和除法中倒数的截断。由于IEEE-754标准只要求单个操作的误差小于最后一位一个单位的一半，因此重复操作中的浮点误差将相加，除非得到纠正。

我的解决方法：

function add(a, b, precision) {
    var x = Math.pow(10, precision || 2);
    return (Math.round(a * x) + Math.round(b * x)) / x;
}

精度是指在加法过程中要保留小数点后的位数。

鉴于没有人提到这一点。。。

一些高级语言（如Python和Java）提供了克服二进制浮点限制的工具。例如：

Python的十进制模块和Java的BigDecimal类，它们在内部使用十进制表示法（与二进制表示法相反）表示数字。两者都有有限的精度，因此它们仍然容易出错，但它们解决了二进制浮点运算中最常见的问题。小数在处理金钱时很好：10美分加20美分总是正好是30美分：>>> 0.1 + 0.2 == 0.3错误>>>十进制（'0.1'）+十进制（'0.2'）==十进制（'0.3'）真的Python的十进制模块基于IEEE标准854-1987。Python的分数模块和Apache Common的BigFraction类。两者都将有理数表示为（分子、分母）对，它们可能给出比十进制浮点运算更精确的结果。

这两种解决方案都不是完美的（特别是如果我们考虑性能，或者如果我们需要非常高的精度），但它们仍然解决了二进制浮点运算的大量问题。

它被打破的方式与你在小学学习并每天使用的十进制（以10为基础）表示法完全相同，只是以2为基础。

要理解，请考虑将1/3表示为十进制值。这是不可能做到的！世界将在你写完小数点后的3之前结束，所以我们写了一些地方，认为它足够准确。

以同样的方式，1/10（十进制0.1）不能以2为基数（二进制）精确地表示为“十进制”值；小数点后的重复模式将永远持续下去。该值不精确，因此无法使用常规浮点方法对其进行精确计算。与基数10一样，还有其他值也显示了这个问题。

浮点舍入错误。从每个计算机科学家应该知道的浮点运算：

将无限多的实数压缩成有限位数需要近似表示。虽然有无限多的整数，但在大多数程序中，整数计算的结果可以存储在32位中。相反，给定任何固定位数，大多数使用实数的计算将产生无法使用那么多位数精确表示的量。因此，浮点计算的结果必须经常舍入，以适应其有限表示。这种舍入误差是浮点计算的特征。

十进制数（如0.1、0.2和0.3）在二进制编码浮点类型中没有精确表示。0.1和0.2的近似值之和与0.3的近似值不同，因此，0.1+0.2==0.3的错误在这里可以更清楚地看到：

#include <stdio.h>

int main() {
    printf("0.1 + 0.2 == 0.3 is %s\n", 0.1 + 0.2 == 0.3 ? "true" : "false");
    printf("0.1 is %.23f\n", 0.1);
    printf("0.2 is %.23f\n", 0.2);
    printf("0.1 + 0.2 is %.23f\n", 0.1 + 0.2);
    printf("0.3 is %.23f\n", 0.3);
    printf("0.3 - (0.1 + 0.2) is %g\n", 0.3 - (0.1 + 0.2));
    return 0;
}

输出：

0.1 + 0.2 == 0.3 is false
0.1 is 0.10000000000000000555112
0.2 is 0.20000000000000001110223
0.1 + 0.2 is 0.30000000000000004440892
0.3 is 0.29999999999999998889777
0.3 - (0.1 + 0.2) is -5.55112e-17

为了更可靠地计算这些计算，您需要对浮点值使用基于十进制的表示。C标准没有默认指定此类类型，而是作为技术报告中描述的扩展。

_Decimal32、_Decimal64和_Decimal128类型可能在您的系统上可用（例如，GCC在选定的目标上支持它们，但Clang在OS X上不支持它们）。