编程与软件工程randomascii.wordpress.com
英特尔把误差界低估了 1.3 quintillion
Intel Underestimates Error Bounds by 1.3 Quintillion
2014 — 2018，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章深入分析了 Intel x87 浮点指令 fsin/fcos 的精度问题：Intel 文档声称的误差上限与实际相差达 1.3×10^18 倍，根源在于大参数的 π 归约使用了精度不足的 π 近似值。作者通过实验展示了在接近 π 的输入下计算结果可能严重偏离真实值。
为什么经久不衰：它揭示了一个被低估多年的硬件级数值精度陷阱，对任何关心浮点计算正确性的人都是经典警示。
HN 评论精选
硬件超越函数指令不可靠，且 Intel 的错误行为已成事实兼容标准
这类问题只有做底层开发的人才知道，其实应该让更多人了解。你真的不该用 x86 硬件超越函数指令。我见过有人拿自己的近似实现和硬件内置函数对比来衡量精度，结果他们的实现可能比硬件还准。我以前在另一家 CPU 厂商工作，我们实现了更精确的 sin/cos，结果一些基准测试反而判定我们“算错了”——因为那些测试硬编码了 Intel 多年来的行为。为了兼容性，更高精度只能作为可选项，默认关闭。
luu查看英文原文
This is one of those things that's well known by people who spend a lot of time doing low-level nonsense that really ought to get wider press. You really don't want to use x86 hardware transcendental instructions. I've seen people try to measure the effectiveness of their approximation by comparing against built-in hardware, but their approximation is probably better than the hardware! If you're not writing your own assembly, you'll be ok on most modern platforms if you just link with "-lm" and use whatever math library happens to be lying around as the default, but it's still possible to get caught by this. On obscure platforms, it's basically a coin flip. I used to work for another CPU vendor, and when we implemented more accurate sin/cos functions, some benchmarks would fail us for getting the wrong result. Turns out those benchmarks hardcode a check for a couple results, and that check is based on what Intel has been doing for ages. My recollection is that we had a switch to enable the extra accuracy, but that it wasn't enabled by default because it was too much of a risk to break compatibility with Intel. If that sounds too risk averse, there's a lot of code out there that depends on your processor precisely matching Intel's behavior on undefined flags and other things that code has no business depending on. It's basically the same thing Raymond Chen is always talking about, but down one level of abstraction. I've seen what happens if you just implement something that matches the "spec" (the Intel manual) and do whatever you want for "undefined" cases. You get a chip that's basically useless because existing software will crash on it.
问题根源是参数归约中 π 精度不足，AMD 曾修复但被迫回退以保持兼容
fsin/fcos 的多项式近似只在 [-π/4, π/4] 区间有效，区间外的输入通过除以 π/4 取余再做象限修正来归约。Intel FPU 出问题是因为归约时用了 π/4 的近似值。90 年代中期 AMD 的工程师想出了更精确的归约方法并在 K5 的 FPU 中实现，但下一代 CPU 又改回与 x87 逐位兼容，大概是因为新实现破坏了太多应用。
CurtHagenlocher查看英文原文
Of possible interest, I researched a related issue once and here's what I found: The particular approximation used by the FPU instructions fsin and fcos is valid in the domain [-π /4, π /4]. Inputs outside this domain are reduced by taking the remainder when dividing by π /4 and then using trigonometric identities to fix up values in the other three quadrants (ie sin(x) = sin(π /2 – x) for x in [π /4, π /2]. The Intel FPU is “off” because it uses an approximation for π /4 when performing the reduction. In the mid 90s, some engineers at AMD figured out how to do a more precise reduction and implemented this reduction in the K5 FPU. AMD went back to being bit-for-bit compatible with the x87 behavior in the very next generation of their CPUs, presumably because it either broke or appeared to break too many applications.
该误差在数学上是“后向稳定”的，实际危害比表面看起来小
从数学上看这并非完全糟糕：当 x 接近 π 时，sin(x) 本身是病态的。虽然计算结果的前向误差很大，但总能找到一个与 x 非常接近的 x̄，使得计算值恰好等于 sin(x̄)——也就是说这个过程是后向稳定的，只是前向不稳定。JVM 在 2005 年也遇到过同样问题并用较慢的软件方案解决。
conistonwater查看英文原文
There is a mathematical reason for why this is not completely horrible, even though this would catch you off guard. When x is approximately pi, the function x -> sin(x) is ill-conditioned. [0] So the relative error between the computed value ybar=fl(sin(x)) and the true value y=sin(x) is (ybar-y)/y and is quite large. However: you can find a number xbar that is very close to x, in the sense that (xbar-x)/x is very small, such that the computed "inaccurate" value ybar=fl(sin(x)) matches sin(xbar) exactly. Thus this procedure is backward-stable, but not forward-stable. For "typical" numerically-stable algorithms, this might not be such an issue. Very interesting writeup, anyway. I also found this post by James Gosling [1] describing the same issue, and the slower software workaround implemented in JVM; the post is from 2005. The paper that explain K5's implementation is "The K5 transcendental functions" by Lynch, Ahmed, Schulte, Callaway, Tisdale, but it is behind an academic paywall. [0] http://en.wikipedia.org/wiki/Condition_number [1] https://blogs.oracle.com/jag/entry/transcendental_meditation
Intel 承认误差界限只对小参数成立，这本质上是文档缺陷
Intel 工程师在官方论坛回应称：Pentium 发布时为 x87 超越函数提供了严格的误差界限，手册附录中有 ulp 图表；fsin/fcos 的结果只保证参数小于 π/4 时的精度，因为更大参数的归约只用了 66 位的 π 值。
acqq查看英文原文
https://software.intel.com/en-us/forums/topic/289702 "Shane Story (Intel) Sun, 06/27/2010 - 11:44 (...) rigorous error bounds for most of the x87 transcendental functions (f2xm1, fsincos, fyl2x...) were provided when the Pentium processor released. I recall an appendix in the orginal Pentium manual which showed a collection of ulp (unit in the last place) charts - don't recall the upper bound for all of them but it was something like 1.8 ulps. This would be for double-extended 80 bit fp inputs. Results for the fsin/fcos were for arguments < pi/4 because for the reduction for larger inputs, a 66-bit value of pi (or pi/2) was used." It's really a documentation bug. Sometimes some important details get lost after the documentation rewrites.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选