c# - .NET 的 Double.ToString 方法中的两次错误

Question

在数学上，考虑这个问题的有理数

8725724278030350 / 2**48

哪里**分母中表示求幂，即分母为2到 48权力。 (分数不是最低的，可以减少 2。)这个数字是 正好可表示为 System.Double .它的十进制扩展是

31.0000000000000'49'73799150320701301097869873046875 (exact)

其中撇号不代表丢失的数字，而仅标记四舍五入为 的边界。 15 分别 17 数字是要执行的。

请注意以下事项: 如果此数字四舍五入为 15 位，结果将为 31 (后跟 13 个 0 s)因为接下来的数字( 49... )以 4 开头(意思是向下舍入)。但是如果数字先四舍五入到 17 位，然后再四舍五入到 15 位，结果可能是 31.0000000000001 .这是因为第一次舍入通过增加 49... 向上舍入。数字到 50 (terminates) (接下来的数字是 73... )，然后第二次舍入可能会再次向上舍入(当中点舍入规则表示“远离零舍入”时)。

(当然，还有更多具有上述特征的数字。)

现在，事实证明 .NET 对这个数字的标准字符串表示是 "31.0000000000001" . 问题:这不是一个错误吗？ 通过标准字符串表示，我们指的是 String由参数生成 Double.ToString()实例方法当然与 ToString("G") 产生的相同.

需要注意的一个有趣的事情是，如果你将上面的数字转换为 System.Decimal然后你会得到一个 decimal即 31确切地!见 this Stack Overflow question讨论类型转换 Double 令人惊讶的事实至 Decimal涉及首先四舍五入到 15 位数字。这意味着转换到 Decimal在调用 ToSting() 时进行正确的舍入到 15 位数字做一个不正确的。

综上所述，我们有一个浮点数，当输出给用户时，它是 31.0000000000001 ，但当转换为 Decimal 时(其中 29 位数可用)，变为 31确切地。这是不幸的。

这里有一些 C# 代码供您验证问题:

static void Main()
{
  const double evil = 31.0000000000000497;
  string exactString = DoubleConverter.ToExactString(evil); // Jon Skeet, http://csharpindepth.com/Articles/General/FloatingPoint.aspx 

  Console.WriteLine("Exact value (Jon Skeet): {0}", exactString);   // writes 31.00000000000004973799150320701301097869873046875
  Console.WriteLine("General format (G): {0}", evil);               // writes 31.0000000000001
  Console.WriteLine("Round-trip format (R): {0:R}", evil);          // writes 31.00000000000005

  Console.WriteLine();
  Console.WriteLine("Binary repr.: {0}", String.Join(", ", BitConverter.GetBytes(evil).Select(b => "0x" + b.ToString("X2"))));

  Console.WriteLine();
  decimal converted = (decimal)evil;
  Console.WriteLine("Decimal version: {0}", converted);             // writes 31
  decimal preciseDecimal = decimal.Parse(exactString, CultureInfo.InvariantCulture);
  Console.WriteLine("Better decimal: {0}", preciseDecimal);         // writes 31.000000000000049737991503207
}

上面的代码使用了 Skeet 的 ToExactString方法。如果不想用他的东西(可以通过网址找到)，把上面依赖exactString的代码行删掉就好了.你仍然可以看到 Double有问题的 ( evil ) 是圆形和类型转换的。

附加:

好的，所以我测试了更多数字，这是一个表格:

  exact value (truncated)       "R" format         "G" format     decimal cast
 -------------------------  ------------------  ----------------  ------------
 6.00000000000000'53'29...  6.0000000000000053  6.00000000000001  6
 9.00000000000000'53'29...  9.0000000000000053  9.00000000000001  9
 30.0000000000000'49'73...  30.00000000000005   30.0000000000001  30
 50.0000000000000'49'73...  50.00000000000005   50.0000000000001  50
 200.000000000000'51'15...  200.00000000000051  200.000000000001  200
 500.000000000000'51'15...  500.00000000000051  500.000000000001  500
 1020.00000000000'50'02...  1020.000000000005   1020.00000000001  1020
 2000.00000000000'50'02...  2000.000000000005   2000.00000000001  2000
 3000.00000000000'50'02...  3000.000000000005   3000.00000000001  3000
 9000.00000000000'54'56...  9000.0000000000055  9000.00000000001  9000
 20000.0000000000'50'93...  20000.000000000051  20000.0000000001  20000
 50000.0000000000'50'93...  50000.000000000051  50000.0000000001  50000
 500000.000000000'52'38...  500000.00000000052  500000.000000001  500000
 1020000.00000000'50'05...  1020000.000000005   1020000.00000001  1020000

第一列给出了 Double 的精确值(虽然被截断了)代表。第二列给出了来自 "R" 的字符串表示格式字符串。第三列给出了通常的字符串表示。最后第四列给出了 System.Decimal转换此 Double 的结果.

我们得出以下结论:

通过 ToString() 舍入到 15 位数字并通过转换为 Decimal 舍入到 15 位数字在很多情况下不同意

转换为 Decimal在很多情况下也会错误地舍入，并且这些情况下的错误不能被描述为“两次”错误

就我而言，ToString()似乎产生比 Decimal 更大的数字当他们不同意时转换(无论两轮中的哪一轮正确)

我只尝试过像上面这样的情况。我还没有检查其他“表格”的数量是否存在四舍五入错误。

Answer 1

所以从你的实验来看，似乎 Double.ToString不做正确的舍入。

这是相当不幸的，但并不特别令人惊讶:对二进制到十进制的转换进行正确的舍入非常重要，而且可能非常慢，在极端情况下需要多精度算术。见大卫·盖伊的 dtoa.c代码 here有关正确舍入 double 字符串和字符串 double 转换所涉及的内容的一个示例。 (Python 目前使用此代码的变体来进行浮点到字符串和字符串到浮点的转换。)

即使是当前的 IEEE 754 浮点运算标准也推荐，但并不要求从二进制浮点类型到十进制字符串的转换始终正确舍入。这是第 5.12.2 节“表示有限数字的外部十进制字符序列”中的一个片段。

There might be an implementation-defined limit on the number of significant digits that can be converted with correct rounding to and from supported binary formats. That limit, H, shall be such that H ≥ M+3 and it should be that H is unbounded.

这里M定义为 Pmin(bf) 的最大值所有支持的二进制格式 bf ，以及自 Pmin(float64)定义为 17 .NET 通过 Double 支持 float64 格式类型，M应该至少是 17在网上。简而言之，这意味着如果 .NET 遵循该标准，它将提供至少 20 位有效数字的正确舍入字符串转换。所以看起来好像.NET Double不符合这个标准。

在回答“这是一个错误”问题时，尽管我希望它是一个错误，但我在数字格式文档中可以找到的任何地方似乎都没有任何准确性或 IEEE 754 一致性声明对于.NET。所以它可能被认为是不受欢迎的，但我很难将其称为实际错误。

编辑:Jeppe Stig Nielsen 指出 System.Double MSDN 上的页面指出

Double complies with the IEC 60559:1989 (IEEE 754) standard for binary floating-point arithmetic.

我不清楚这个符合性声明到底应该涵盖什么，但即使对于 IEEE 754 的 1985 年旧版本，所描述的字符串转换似乎也违反了该标准的二进制到十进制要求。

鉴于此，我很乐意将我的评估升级为“可能的错误”。