从 float 转换为 double 会产生不同的结果——相同的代码、相同的编译器、相同的操作系统

Question

编辑：请参阅问题的结尾以获取最新的答案。

我花了数周时间在我的一个软件中寻找一个非常奇怪的错误 维持。长话短说，有一个旧软件在 分发，以及需要匹配输出的新软件 老的。两者（理论上）依赖于一个公共库。 [1]然而，我不能 复制由库的原始版本生成的结果， 即使库的两个版本的源匹配。实际上 有问题的代码非常简单。原始版本看起来像这样（ “voodoo”评论不是我的）：[2]

// float rstr[101] declared and initialized elsewhere as a global

void my_function() {
    // I have elided several declarations not used until later in the function
    double tt, p1, p2, t2;
    char *ptr;

    ptr = NULL;
    p2 = 0.0;
    t2 = 0.0; /* voooooodoooooooooo */

    tt = (double) rstr[20];
    p1 = (double) rstr[8];

    // The code goes on and does lots of other things ...
}

我包含的最后一条语句是出现不同行为的地方。在里面 原始程序，rstr[8] 的值为 101325.，并将其转换为 double[3] 并分配它，p1 具有值101324.65625。同样，tt 最终得到值373.149999999996。我已经确认了这些价值观 调试打印和检查调试器中的值（包括检查 十六进制值）。这在任何意义上都不足为奇，正如预期的那样 浮点值。

在同一版本库的测试包装器中（以及在任何调用中） 到库的重构版本），第一个分配（到tt） 产生相同的结果。 然而，p1 以 101325.0 结尾，与原始匹配 rstr[8] 中的值。这种差异虽然很小，但有时会产生巨大的 取决于p1 的值的计算变化。

我的测试包装很简单，并且与原始的包含模式相匹配 完全正确，但消除了所有其他上下文：

#include "the_header.h"

float rstr[101];
int main() {
    rstr[8] = 101325.;
    rstr[20] = 373.15;

    my_function();
}

无奈之下，我什至不厌其烦地看了看 VC6生成的反汇编。

4550:   tt = (double) rstr[20];
0042973F   fld         dword ptr [rstr+50h (006390a8)]
00429745   fstp        qword ptr [ebp-0Ch]
4551:   p1 = (double) rstr[8];
00429748   fld         dword ptr [rstr+20h (00639078)]
0042974E   fstp        qword ptr [ebp-14h]

VC6 调用同一库函数时生成的版本 测试代码包装器（它与 VC6 为我的重构生成的版本相匹配 库的版本）：

60:       tt = (double) rstr[20];
00408BC8   fld         dword ptr [_rstr+50h (0045bc88)]
00408BCE   fstp        qword ptr [ebp-0Ch]
61:       p1 = (double) rstr[8];
00408BD1   fld         dword ptr [_rstr+20h (0045bc58)]
00408BD7   fstp        qword ptr [ebp-14h]

我能看到的唯一区别是，除了数组在内存中的存储位置和 这在程序中发生了多长时间，是领先的_ 在第二个中引用rstr。通常，VC6 使用前导下划线表示 使用函数进行名称修改，但我找不到任何关于它的文档 使用数组指针进行名称修改。我也看不出为什么这些会产生 在任何情况下都会产生不同的结果，除非涉及名称修改 以不同的方式读取从指针访问的数据。

我可以确定两者之间的唯一其他区别（除了调用 context) 是原来是一个基于 MFC 的 Win32 应用程序，而 后者是一个非 MFC 控制台应用程序。这两个是另外配置的 同样的方式，它们是用相同的编译标志和反对 相同的 C 运行时。

任何建议将不胜感激。

---

编辑：解决方案，正如 several answers 非常有帮助地指出的那样，是检查二进制/十六进制值并比较它们以确保我认为的东西在事实上是相同的。事实证明并非如此——尽管我强烈反对。

在这里，我可以吃一些不起眼的馅饼，并承认虽然我认为我检查了这些值，但实际上我检查了一些其他密切相关的值——我只有在去的时候才发现这一点回头再看数据。事实证明，rstr[8] 中设置的值非常略有不同，因此转换为 double 突出显示了非常细微的差异，然后这些差异以我的方式在整个程序中传播注意到。

我可以根据两个程序的工作方式来解释初始化的差异。具体来说，在一种情况下，rstr[8] 是根据用户对 GUI 的输入指定的（在这种情况下也是转换计算的产物），而在另一种情况下，它是从存储它的文件中读入的一些精度损失。有趣的是，在这两种情况下，它实际上都不是完全 101325.0，即使是从存储为1.01325e5的文件中读取的情况。

这将教会我仔细检查我对这些事情的双重检查。非常感谢Eric Postpischil 和unwind 提示我再次检查并及时反馈。这非常很有帮助。

---

脚注

1. 实际上，原来的“库”是一个包含所有 内联完成的实现。标头是通过#include 和 通过extern 语句引用的函数。我已经解决了这个问题 库的重构版本实际上是一个库，但请参阅 剩下的问题。
2. 请注意，变量名不是我的，而且很糟糕。同样与 使用全局变量，这在这个软件中很猖獗。我离开了 在/* voooooodoooooooooo */ 评论中，因为它说明了…… 不寻常的……我的前任的编程实践。我认为那个元素是 存在，因为这最初是从 Fortran 和开发人员翻译而来的 曾将其用作处理某种内存错误的方法。线路有 对代码的实际行为没有任何影响。
3. 我很清楚这里实际上不需要演员，但是这个 是原始库的工作方式，我无法修改它。

Answer 1

这个：

在原程序中，rstr[8] 的值为 101325.，将其转换为 double[3] 并赋值后，p1 的值为 101324.65625

暗示float 的值实际上并不完全是 101325.0，因此当您转换为 double 时，您会看到更多的精度。我会（高度）怀疑您检查float 值的方法，自动（隐式和静默）四舍五入时打印非常常见于浮点数。检查位模式并使用系统上已知的浮点格式对其进行解码，以确保您没有被欺骗。

Answer 2

可能性是：

1. 尽管报告了观察结果，rstr[8] 在分配给p1 之前的原始程序中的值是 101324.65625，而不是报告的 101325。
2. 尽管报告了观察结果，p1 在分配后立即没有值 101324.65625。
3. 程序未正确执行分配（包括转换为double）。

要测试 1，请在分配前仔细检查 rstr[8] 的值。我建议：

• 将值打印或记录为 20 位有效数字，并且
• 打印或记录构成 rstr[8] 的字节，然后以 IEEE-754 64 位二进制格式解释字节，或
• 使用调试器完成上述两项工作。

此外，我建议通过将值 101324.65625 注入rstr[8]（通过赋值或调试器）并以与上面使用的相同方式显示它来测试浮点值是否显示得足够好。

要测试 2，请在分配后立即仔细检查 p1 的值。我建议以上，适用于p1 而不是rstr[8]。

问题中显示的反汇编代码似乎反驳了 3。但是，我会考虑这些测试：

• 测试这些指令是否实际执行，可能通过在调试器中对它们设置断点。
• 在调试器中的指令执行前立即检查它们。
• 检查要加载的内存、加载指令后的浮点寄存器以及存储后的内存。

Answer 3

您需要做的（明智的调试）是在旧版本和重构版本之间获取 rstr[20] 和 rstr[8] 的二进制值。 tt 和 p1 的二进制值也不会受到伤害。这将证明数组的初始化是相同的。将 double 分配给 float 数组，然后将其转换回 double 并不是无损的。

我能想到的唯一奇怪的情况是 FPU 的舍入模式在旧程序和重构程序之间设置不同。检查“_control_fp(”、“fesetround(”或“fenv.h”)的源代码。

Answer 4

浮点的第一条规则是结果是近似值，永远不应该假设是精确的。

编译器和 CPU 都能够进行大量优化，优化中的微小差异（包括缺乏优化）可能会导致最终“近似值”的微小差异。这包括各种各样的事情，比如执行操作的顺序（例如，不要假设“（x + y）+ z”与“x +（y + z）”相同），如果有任何事情是预先的由编译器完成（例如常量折叠），是否内联，等等。

例如，（内部）80x86 使用比双精度更精确的 80 位“扩展精度”浮点；因此，简单地将结果存储为 double 并再次加载它会导致不同的结果重新使用 FPU 寄存器中已经存在的（更高精度）值。

我的主要意思是，如果你得到的确切值如此重要，那么你根本就不应该使用浮点数（考虑“大理性”之类的东西）。