“计算器错误”是一个代码问题？

我在很多博客文章中都看到了这个错误： http : //atifsiddiqui.blogspot.com/2010/11/windows-calculator-bug.html

这个bug是代码错误还是math不精确？

我想知道如果它真的是一个错误，如何得到多年未被发现？

我应该注意什么，以确保它不会发生在我的自定义计算器程序中。

UNIX shell脚本中的浮点运算

什么是x86-64长两倍？

SET命令 – 浮点数？

在x86 linux上使用软件浮点

浮点常量比较 – （0.0？1：0）

针对AT91SAM9 ARM处理器Linux用户空间程序的FFT和math优化

在linux下gcc（5.4.0）是否遵守IEEE754规则？

睡在某些数字永远持续在Linux bash

浮点比较失败没有任何明显的原因（Linux上的32位X86）

有什么办法可以确保浮点的输出在不同的操作系统中是一样的吗？

是的，这是一个错误。 事实上，它有一个技术性的解释（这是非常难以接受的）并不能免除它成为一个错误。 如果这不是一个错误，那么你或者争论 – 正如我们所有人偶尔 – “这是一个功能”，或者说这是一个系统的限制。

为了解决这个问题，我建议你将每个结果都舍入到一个可接受的精度级别，以消除非常小的错误。 正如其他答案所示，问题在于，在你的计算器中，'4'的平方根不是'2'，而是一个非常接近于2的数字。为了解决这个问题，结果为10,20,30个小数位无论你能负担得起

我认为任何计算器引擎都应该有一个基本的精度级别，这个级别的精度超过了可达到的精度级别，这样用户不能访问浮点运算的极限。 如果你走这条道路，你将会失去一种“准确性”的形式，但是你只要说明你的计算器精确到n位小数。 特别是如果解决了这个问题，那更是不能接受的。

然而，这不是一个大问题，是吗？

顺便说一下，我曾经在一家供应商提供了一些应该计算一些复利利率的软件的财务应用程序。 他们的计算总是关闭的。 他们认为这是“由于浮点算术”，并试图教育我在这个问题上; 但是他们的算法没有了。 当按美元计算利率时，我们总是在每次迭代（日，周，月，年或其他）之后总计。 根据不同的情况，它可能是最接近的美元，最接近的美分，或最接近的百分之一美分 – 但这是一个可量化的数额，我们从来不会每年复合百分之一分。 如果你想避免本质上是一个计算舍入错误，这是你应该采取的方法。

正如其他人所说，这不是一个错误，而是涉及计算机在内部表示浮点数并处理浮点运算的方式。 事实证明你和我不认为在浮点数学，但电脑。 而“浮点”是指一个二进制点，而不是一个小数点。

它返回的数值实际上非常接近于0（我认为我们都可以认同的是“正确的”十进制答案）。 发生了什么事是sqrt函数本身返回的数字非常接近2，但是由于浮点类型的限制，这个数字不能在内部存储为2。 输出结果是数字“2”，因为计算器只是将其四舍五入来显示，知道“2”是您所期望的答案。 但是当你从sqrt(4)内部存储表示中减去2时，你并不完全是0，因为内部存储的数字不完全是2。

每个程序员都应该真正阅读“计算机科学家应该知道什么是浮点运算” ，它解释了这种行为（特别是关于“精确”和“二进制到十进制转换”的部分）以及许多其他令人难以置信的细节计算机将内部数字表示为浮点类型。

我同意@Kirk broadhurst，这在技术上是一个bug，因为sqrt（4）-2的结果严格为0，而Calc给出了一个不同的（尽管非常接近）的结果。 通常我们可以忍受这种不准确的事实在这里是无关紧要的。 严格地说，程序员应该找到不同的方法来解决这类问题。

恕我直言，这里有很多人没有看到的是，4和2在IEEE浮点格式可以精确表示。 作为2的一个自然的力量可以无限精确地表示，所以指责FP格式的理由也是不相关的。 问题来自sqrt（）函数算法，而不是来自FP存储格式。

它是一个常见的浮点问题。 如果你拿1/3例子，然后乘以3浮点数，你不会得到1回来，但0.9999999999999999999999 ，或1.000000000000000000001 。 Windows计算器使用了一些算法来尽量减少像我刚刚解释的情况，但可能是他们没有处理所有特殊情况….

它不完全是一个错误，更多的是一个可用性问题，因为他们处理一些案件，但不是全部..

这不是一个错误（电脑这样工作！）。 SO有很多关于这个话题的问题。 例如，搜索“JavaScript数学中断”。

有经验的计算机用户也应该认识到，实际上与零相同。

如果你想避免这样的事情，你可以将每个结果转换为字符串。 -8.1648465955514287168521180122928e-39将舍入为0.但是，如果你正在编写一个非常先进的计算器，能够处理普朗克常数（如果你这样做，普朗克常数被认为等于零，这是不好的）。 一个非常好的选择是使用符号数学，但是这不需要花费几分钟时间来编写一个计算器，而是几个月/年…

纯粹的猜测，我会说这是因为计算器没有得到2平方根的结果（取决于它如何计算根）。 但是当结果远离零时，它只是将显示屏四舍五入。 但是当数字接近于零时，就会显示确切的结果。

对于一个自己的计算器，你可能不会得到这样的结果，只是没有这么高的准确性（当使用编程语言给出的正常数学特征时，你通常没有这样的准确性）。

它比正常的浮点问题稍微复杂一些，因为calc实际上使用任意的精确数学。 不过，如同雷蒙德所说的那样，它似乎只是对基本操作使用了无限精度

今天，Calc的内部计算对于基本操作（加法，减法，乘法，除法）具有无限精度，而对于高级操作（平方根，超越算子）则具有32位精度。

所以可以推测平方根实际上导致了一个非常接近的值，但不是2，但是显示为2，在精确的相减之后，你留下了一个非常接近0的数字，它不显示为0，这是一个错误？ 依靠。