Python 在哪些系统上不使用 IEEE-754 双精度浮点数

Question

Python 对 IEEE 754 浮点运算进行了各种引用，但不保证1 2它将在运行时使用。因此我想知道哪里不是这种情况。

CPython 源代码遵循 C 编译器使用的任何内容double，实际上是binary64我所知道的所有常见系统上的 IEEE 754-2008，例如：

• Linux 和 BSD 发行版（例如 FreeBSD、OpenBSD、NetBSD）
  • 英特尔 i386/x86 和 x86-64
  • ARM：AArch64
  • 功率：PPC64
• MacOS 所有支持的架构均兼容 754
• Windows x86 和 x86-64 系统

我知道还有其他已知的平台可以构建，但不知道这些平台在实践中如何运作。

Answer 1

更新：自从我在下面写下原始答案以来，情况略有变化。CPython 版本 3.11 及更高版本现在要求平台 Cdouble遵循 IEEE 754 二进制 64 格式。这主要是为了方便开发人员——它允许我们删除实际上几乎无法测试的特殊情况代码。Python 语言仍然没有规定需要 IEEE 754，并且没有什么可以阻止有人修补 CPython 以添加对不遵循 IEEE 754 的不寻常平台的支持；将结果称为“Python”仍然是合理的。此外，即使对于 CPython，也没有任何书面保证该格式将是 IEEE 754 二进制 64 - 开发人员可以决定逆转 IEEE 754 二进制 64 要求。（我个人认为这种情况极不可能发生，至少在未来十年内是这样，但这是有可能的。）

double理论上，正如您所说，CPython 被设计为可在任何平台上构建和使用，而无需关心 C使用的浮点格式。

在实践中，有两件事是正确的：

• To the best of my knowledge, CPython has not met a system that's not using IEEE 754 binary64 format for its C double within the last 15 years (though I'd love to hear stories to the contrary; I've been asking about this at conferences and the like for a while). My knowledge is a long way from perfect, but I've been involved with mathematical and floating-point-related aspects of CPython core development for at least 13 of those 15 years, and paying close attention to floating-point related issues in that time. I haven't seen any indications on the bug tracker or elsewhere that anyone has been trying to run CPython on systems using a floating-point format other than IEEE 754 binary64.

• I strongly suspect that the first time modern CPython does meet such a system, there will be a significant number of test failures, and so the core developers are likely to find out about it fairly quickly. While we've made an effort to make things format-agnostic, it's currently close to impossible to do any testing of CPython on other formats, and it's highly likely that there are some places that implicitly assume IEEE 754 format or semantics, and that will break for something more exotic. We have yet to see any reports of such breakage.

There's one exception to the "no bug reports" report above. It's this issue: https://bugs.python.org/issue27444. There, Greg Stark reported that there were indeed failures using VAX floating-point. It's not clear to me whether the original bug report came from a system that emulated VAX floating-point.

I joined the CPython core development team in 2008. Back then, while I was working on floating-point-related issues I tried to keep in mind 5 different floating-point formats: IEEE 754 binary64, IBM's hex floating-point format as used in their zSeries mainframes, the Cray floating-point format used in the SV1 and earlier machines, and the VAX D-float and G-float formats; anything else was too ancient to be worth worrying about. Since then, the VAX formats are no longer worth caring about. Cray machines now use IEEE 754 floating-point. The IBM hex floating-point format is very much still in existence, but in practice the relevant IBM hardware also has support for IEEE 754, and the IBM machines that Python meets all seem to be using IEEE 754 floating-point.

Rather than exotic floating-point formats, the modern challenges seem to be more to do with variations in adherence to the rest of the IEEE 754 standard: systems that don't support NaNs, or treat subnormals differently, or allow use of higher precision for intermediate operations, or where compilers make behaviour-changing optimizations.

The above is all about CPython-the-implementation, not Python-the-language. But the story for the Python language is largely similar. In theory, it makes no assumptions about the floating-point format. In practice, I don't know of any alternative Python implementations that don't end up using an IEEE 754 binary format (if not semantics) for the float type. IronPython and Jython both target runtimes that are explicit that floating-point will be IEEE 754 binary64. JavaScript-based versions of Python will similarly presumably be using JavaScript's Number type, which is required to be IEEE 754 binary64 by the ECMAScript standard. PyPy runs on more-or-less the same platforms that CPython does, with the same floating-point formats. MicroPython uses single-precision for its float type, but as far as I know that's still IEEE 754 binary32 in practice.