以下表达式在C＃中计算为List 1：
false我认为它在大多数实现IEEE 754的其他编程语言中都是这样做的，因为(1 + 1 + 0.85) / 3 <= 0.95
评估为(1 + 1 + 0.85) / 3，大于0.95000000000000007。
但是，即使Excel should implement most of IEEE 754 too，以下在Excel 2013中评估为TRUE：
0.95有什么具体原因吗？上面链接的文章没有提到任何可能导致此行为的Excel自定义实现。你能告诉Excel严格按照IEEE 754进行舍入吗？
请注意，即使大多数Excel问题都应该在superuser.com上提出，但这个问题涉及浮点运算，这是编程语言中的常见问题。从这个问题的主题来看，Excel是一种编程语言，如C＃或Java。
答案 0 :(得分：4)
article that you linked to明确表示在0附近做一些非标准的事情：
值达到零时的示例 1.在Excel 95或更早版本中，在新工作簿中输入以下内容：A1：= 1.333 + 1.225-1.333-1.225
2.右键单击单元格A1，然后单击“设置单元格格式”。在数字选项卡上，单击类别下的科学。将十进制位置设置为15。 Excel 95不显示0，而是显示-2.22044604925031E-16。
然而，Excel 97引入了一种尝试纠正的优化 对于这个问题。应该进行加法或减法运算 在值为或非常接近零，Excel 97及更高版本将 补偿由于转换而引入的任何错误 来自二进制文件的操作数。
未指定的“尝试纠正此问题的优化”确实意味着当需要与IEEE 754达成严格协议时，应谨慎使用Excel进行数值计算。也许使用VBA（不太可能有这种“优化”？）可能是一种解决方法。