将decimal转换为double时的奇怪行为

Question

我遇到了奇怪的问题时，铸造小数到双倍。

以下代码返回true：

Math.Round(0.010000000312312m, 2) == 0.01m //true

但是，当我将其强制转换为双倍时，它返回false：

(double)Math.Round(0.010000000312312m, 2) == (double)0.01m //false

这是记录在案的行为吗？当我被迫将decimal转换为Double时，我如何避免它？

Visual Studio的截图：

将Math.round铸造为双倍me，结果如下：

(double)Math.Round(0.010000000312312m, 2)   0.0099999997764825821   double
(double)0.01m   0.01    double

null

不幸的是，我不能在较小的项目中重现这个问题。我想埃里克的回答解释了原因。

Answer 1

人们在这里的评论中报告说，有时比较的结果是真的，有时是假的。

不幸的是，这是意料之中的。C#编译器、抖动和CPU都被允许在超过64位双精度的双精度上执行算术，因为它们认为合适。这意味着，有时看起来像“相同”的计算的结果在一次计算中可以以64位精度完成，在另一次计算中可以以80或128位精度完成，这两个结果在最后一位可能不同。

让我确保你明白我所说的“他们认为合适的”是什么意思。无论出于什么原因，你都可以得到不同的结果。在debug和Retail中可以得到不同的结果。如果让编译器在常量中进行计算，而让运行时在运行时进行计算，则可以得到不同的结果。调试器运行时可以得到不同的结果。您可以在运行库和调试器的表达式计算器中获得不同的结果。任何理由。双重算术天生就不可靠。这要归功于浮点芯片的设计；在这些芯片上的双重算术不可能在不造成相当大的性能损失的情况下变得更可重复。

顺便说一句，我已经在StackOverflow上多次回答了关于这个问题的各种变体。例如：

为什么在C#中用括号分隔和用语句分隔时浮点精度不同？

另外，如果您需要“拆开”一个double来查看它的位，我不久前编写的这段方便的代码非常有用。它要求您安装Solver Foundation，但这是免费下载的。

http://ericlippert.com/2011/02/17/looking-inside-a-double/