浮点误差的确定性有多大？

Question

我知道浮点计算存在准确性问题，并且有很多问题可以解释原因。 我的问题是，如果我运行相同的计算两次，我是否可以始终依赖它产生相同的结果？ 哪些因素可能会影响这个？

• 计算之间的时间？
• CPU当前状态？
• 硬件不同？
• 语言/平台/操作系统？
• 太阳耀斑？

我有一个简单的物理模拟，并且想记录会话以便可以重播。 如果计算可以信赖，那么我只需要记录初始状态加上任何用户输入，并且我应该始终能够准确地重现最终状态。 如果计算不准确，开始时的错误可能会在模拟结束时产生巨大的影响。

我目前在 Silverlight 工作，但有兴趣知道这个问题是否可以得到一般性的回答。

更新：最初的答案表明是，但显然这并不完全明确，正如所选答案的评论中所讨论的那样。 看来我必须做一些测试，看看会发生什么。

Answer 1

据我了解，只有当您处理相同的指令集和编译器，并且您运行的任何处理器都严格遵守相关标准（即 IEEE754）时，才能保证获得相同的结果。 也就是说，除非您正在处理一个特别混乱的系统，否则运行之间的任何计算偏差都不太可能导致错误行为。

我知道的具体问题：

1. 某些操作系统允许您以破坏兼容性的方式设置浮点处理器的模式。

2. 浮点中间结果在寄存器中通常使用80位精度，但在内存中仅使用64位精度。 如果程序以更改函数内寄存器溢出的方式重新编译，则与其他版本相比，它可能会返回不同的结果。 大多数平台都会为您提供一种方法，强制将所有结果截断为内存中的精度。

3. 标准库函数可能会因版本而异。 我发现 gcc 3 与 4 中存在一些并不罕见的例子。

4. IEEE 本身允许一些二进制表示有所不同......特别是 NaN 值，但我不记得细节了。

Answer 2

简而言之，根据 IEEE 浮点标准，浮点计算完全是确定性的，但是并不意味着它们可以在机器、编译器、操作系统等之间完全重现。

这些问题的详细答案以及更多问题可以在可能是关于浮点的最佳参考文献 David Goldberg 的 每个计算机科学家都应该了解浮点运算。 请跳至有关 IEEE 标准的部分以了解关键详细信息。

简要回答您的要点：

• 计算和状态之间的时间
  跟CPU关系不大
  这。

• 硬件会影响事物（例如，某些 GPU 不会影响事物）
  IEEE 浮点兼容）。

• 语言、平台和操作系统也可以
  影响事物。 要获得比我能提供的更好的描述，请参阅 Jason Watkins 的回答。 如果您使用 Java，请查看 Kahan 的对 Java 浮点不足的抱怨.

• 希望太阳耀斑可能很重要
  很少。 我不会太担心，因为如果
  它们确实很重要，那么其他一切也都搞砸了。 我会将其与担心 EMP 归为同一类别。

最后，如果您对相同的初始输入执行相同的浮点计算序列，那么事情应该可以很好地重播。 确切的顺序可能会根据您的编译器/操作系统/标准库而改变，因此您可能会以这种方式遇到一些小错误。

通常在浮点中遇到问题的地方是，如果您有一个数值不稳定的方法，并且您从大约相同但不完全相同的 FP 输入开始。 如果您的方法稳定，您应该能够保证一定容差内的重现性。 如果您想要更多详细信息，请查看上面链接的 Goldberg 的 FP 文章或获取有关数值分析的介绍文本。

Answer 3

我认为您的困惑在于浮点的不准确性类型。 大多数语言都实现 IEEE 浮点标准 该标准规定了浮点数中的各个位如何/double 用于产生数字。 通常，浮点数由四个字节和一个双八字节组成。

两个浮点数之间的数学运算每次都具有相同的值（按照标准中的规定）。

不准确来自于精度。 考虑 int 与 float。 两者通常占用相同数量的字节 (4)。 然而，每个数字可以存储的最大值却截然不同。

• int：大约20亿
• float：3.40282347E38（相当大）

差异在中间。 int，可以表示 0 到大约 20 亿之间的每个数字。 然而浮动却不能。 它可以表示 0 到 3.40282347E38 之间的 20 亿个值。 但这留下了无法表示的整个值范围。 如果数学方程达到这些值之一，则必须四舍五入为可表示的值，因此被认为是“不准确的”。 您对不准确的定义可能会有所不同:)。

Answer 4

另外，虽然 Goldberg 是一个很好的参考，但原文也是错误的：IEEE754 不保证可移植。 考虑到这种说法是基于浏览文本而做出的，我怎么强调都不为过。 该文档的更高版本包括专门讨论此问题的部分 ：

许多程序员可能没有意识到，即使一个程序仅使用 IEEE 标准规定的数字格式和运算，也可以在不同的系统上计算出不同的结果。 事实上，该标准的作者旨在允许不同的实现获得不同的结果。

Answer 5

C++ FAQ 中的这个答案可能是最好的描述：

http: //www.parashift.com/c++-faq-lite/newbie.html#faq-29.18

不仅不同的体系结构或编译器可能会给您带来麻烦，浮点数在同一体系结构或编译器中已经以奇怪的方式表现程序。 正如常见问题解答指出的那样，如果 y == x 为 true，则仍然意味着 cos(y) == cos(x) 将为 false。 这是因为 x86 CPU 使用 80 位计算该值，而该值在内存中以 64 位存储，因此您最终将截断的 64 位值与完整的 80 位值进行比较。

计算仍然是确定性的，从某种意义上说，运行相同的编译二进制文件每次都会给你相同的结果，但是当你稍微调整源代码、优化标志或使用不同的编译器编译它时，所有的赌注都会消失。可以发生。

实际上，我的情况并没有那么糟糕，我可以在 32 位 Linux 上使用不同版本的 GCC 一点一点地重现简单的浮点数学，但当我切换到 64 位 Linux 时，结果不再相同。 在 32 位上创建的演示录音无法在 64 位上运行，反之亦然，但在同一架构上运行时可以正常运行。

Answer 6

由于您的问题被标记为 C#，因此值得强调 .NET 上面临的问题：

1. 浮点数学不具有关联性 - 也就是说，(a + b) + c 不能保证等于 a + (b + c) ;
2. 不同的编译器将以不同的方式优化您的代码，这可能涉及重新排序算术运算。
3. 在 .NET 中，CLR 的 JIT 编译器将动态编译您的代码，因此编译取决于运行时计算机上的 .NET 版本。

这意味着，您不应依赖 .NET 应用程序在不同版本的 .NET CLR 上运行时生成相同的浮点计算结果。

例如，在您的情况下，如果您记录模拟的初始状态和输入，然后安装更新 CLR 的服务包，则您的模拟在下次运行时可能不会以相同的方式重放。

请参阅 Shawn Hargreaves 的博客文章 浮点数学是确定性的吗？ 进行与 .NET 相关的进一步讨论。

Answer 7

抱歉，但我忍不住认为每个人都没有抓住重点。

如果不准确性对您正在做的事情很重要，那么您应该寻找不同的算法。

你说如果计算不准确，开始时的错误可能会在模拟结束时产生巨大的影响。

我的朋友不是模拟的。 如果由于舍入和精度造成的微小差异而得到截然不同的结果，那么很可能所有结果都没有任何有效性。 仅仅因为您可以重复结果并不意味着它就变得更加有效。

对于任何包含测量或非整数计算的重要现实世界问题，引入小错误来测试算法的稳定性始终是一个好主意。

Answer 8

嗯。 由于 OP 要求使用 C#：

C# 字节码 JIT 是确定性的还是在不同的运行之间生成不同的代码？ 我不知道，但我不会相信吉特。

我可以想到这样的场景：JIT 具有一些服务质量功能，并决定花更少的时间进行优化，因为 CPU 在其他地方进行大量的数字运算（想想后台 DVD 编码）？ 这可能会导致细微的差异，并可能在以后导致巨大的差异。

此外，如果 JIT 本身得到改进（也许作为服务包的一部分），生成的代码肯定会发生变化。 80位内部精度问题已经提到过。

Answer 9

这不是您问题的完整答案，但这里有一个示例，证明 C# 中的双重计算是不确定的。 我不知道为什么，但看似不相关的代码显然会影响下游双重计算的结果。

1. 在 Visual Studio 版本 12.0.40629.00 Update 5 中创建新的 WPF 应用程序，并接受所有默认选项。

2. 将 MainWindow.xaml.cs 的内容替换为：

   使用系统； 
     使用系统.Windows； 
   
     命名空间 WpfApplication1 
     { 
         /// <摘要> 
         /// MainWindow.xaml 的交互逻辑 
         ///  
         公共部分类 MainWindow : 窗口 
         { 
             公共主窗口（） 
             { 
                 初始化组件(); 
                 内容 = FooConverter.Convert(new Point(950, 500), new Point(850, 500)); 
             } 
         } 
   
         公共静态类 FooConverter 
         { 
             公共静态字符串转换（点curIPJos，点oppIJPos） 
             { 
                 var ij = " 绝缘接头"; 
                 var deltaX = oppIJPos.X - curIPJos.X; 
                 var deltaY = oppIJPos.Y - curIPJos.Y; 
                 var teta = Math.Atan2(deltaY, deltaX); 
                 字符串结果； 
                 if (-Math.PI / 4 <= teta && teta <= Math.PI / 4) 
                     结果 = "左" + ij; 
                 else if (Math.PI / 4 < teta && teta <= Math.PI * 3 / 4) 
                     结果 = "顶部" + ij; 
                 否则 if (Math.PI * 3 / 4 

3. 将构建配置设置为“Release”并构建，但不要在 Visual Studio 中运行。

4. 双击生成的 exe 来运行它。
5. 请注意，该窗口显示“底部绝缘接头”。

6. 现在在“字符串结果”之前添加此行：

   字符串调试 = teta.ToString(); 
     

7. 重复步骤 3 和 4。

8. 请注意，窗口显示“Right Insulated Joint”。

此行为在同事的机器上得到了证实。 请注意，如果满足以下任一条件，则窗口始终显示“右绝缘接头”：exe 从 Visual Studio 中运行、exe 是使用调试配置生成的，或者在项目属性中未选中“首选 32 位”。

弄清楚发生了什么是相当困难的，因为任何观察过程的尝试似乎都会改变结果。

Answer 10

很少有 FPU 符合 IEEE 标准（尽管他们声称）。 所以在不同的硬件上运行相同的程序确实会得到不同的结果。 结果可能出现在极端情况下，作为在软件中使用 FPU 的一部分，您应该已经避免这种情况。

IEEE 错误通常会在软件中进行修补，您确定您当前运行的操作系统包含来自制造商的正确陷阱和修补程序吗？ 操作系统更新之前或之后怎么样？ 是否删除了所有错误并添加了错误修复？ C 编译器是否与所有这些同步，并且 C 编译器是否生成正确的代码？

测试这一点可能是徒劳的。 在交付产品之前您不会看到问题。

遵守 FP 规则 1：切勿使用 if(something==something) 比较。 IMO 的第二条规则与 ascii 到 fp 或 fp 到 ascii（printf、scanf 等）有关。 与硬件相比，那里存在更多的准确性和错误问题。

随着每一代新硬件（密度）的出现，太阳的影响变得更加明显。 我们已经在行星表面的 SEU 方面遇到了问题，因此独立于浮点计算，您将会遇到问题（很少有供应商愿意关心，因此预计新硬件会更频繁地崩溃）。

由于消耗大量逻辑，fpu 可能会非常快（单个时钟周期）。 不比整数 alu 慢。 不要将此与像 alus 这样简单的现代 fpu 混淆，fpu 很昂贵。 （alus 同样消耗更多逻辑来进行乘法和除法，以将其降低到一个时钟周期，但它几乎没有 fpu 那么大）。

遵循上面的简单规则，多研究一下浮点，了解随之而来的缺点和陷阱。 您可能需要定期检查无穷大或 nan。 您的问题更有可能出现在编译器和操作系统中，而不是硬件中（通常不仅仅是 fp 数学）。 如今，现代硬件（和软件）从定义上来说就充满了错误，因此请尽量减少软件运行时的错误。