【问题标题】：Convert.ToDouble(decimal) unexpected loss precision [duplicate]Convert.ToDouble(decimal) 意外损失精度
【发布时间】：2017-03-18 09:13:50
【问题描述】：

考虑以下代码：

double d = 1478110092.9070129;
decimal dc = 1478110092.9070129M;

Console.WriteLine(d.ToString("R"));
Console.WriteLine(dc);

Console.WriteLine(Convert.ToDouble(dc).ToString("R"));
Console.WriteLine(double.Parse(dc.ToString()).ToString("R"));

这会生成以下内容：

1478110092.9070129
1478110092.9070129
1478110092.9070127
1478110092.9070129

我的问题是 Convert.ToDouble 中发生了什么？显然这个数字可以用双精度表示？

【问题讨论】：

我们开始吧，我认为这个链接应该可以阅读csharpindepth.com/Articles/General/FloatingPoint.aspx
有些数字不能用二进制精确表示，这就是为什么需要精确时使用decimal。
double 可能是一个近似值，但是当我们调用 ToString("R") 时，double 类型解析为以 129 结尾的数字，那么为什么 ConvertToDouble 从以 129 结尾的小数返回 127？

标签： c#

【解决方案1】：

要了解为什么会发生这种情况，我们需要研究 Decimal 的内部结构。

在the source for Convert.ToDouble(Decimal) 中我们看到了

public static double ToDouble(decimal value) {
    return (double)value;
}

在 Decimal 的源代码中，我们可以看到 its explicit conversion operator for double

    public static explicit operator double(Decimal value) {
        return ToDouble(value);
    }

还有它的double ToDouble(Decimal) call

[System.Security.SecuritySafeCritical]  // auto-generated
[MethodImplAttribute(MethodImplOptions.InternalCall)]
public static extern double ToDouble(Decimal d);\

然后我们需要去the native implementation of the ToDouble call

FCIMPL1(double, COMDecimal::ToDouble, FC_DECIMAL d)
{
    FCALL_CONTRACT;

    ENSURE_OLEAUT32_LOADED();

    double result = 0.0;
    // Note: this can fail if the input is an invalid decimal, but for compatibility we should return 0
    VarR8FromDec(&d, &result);
    return result;
}
FCIMPLEND

这将我们引向VarR8FromDec，这是OleAut32.dll 中的一个windows 函数，我们没有源代码。

问题可能是OleAut32.dll 没有进行它可能进行的最大精度转换。

如果您想以最大精度进行转换，您需要先转到 R 格式的字符串，然后解析字符串。

如果您好奇，我通过反编译器运行 VarR8FromDec，这是它在内部执行的操作

HRESULT __stdcall VarR8FromDec(const DECIMAL *pdecIn, DOUBLE *pdblOut)
{
  BYTE v2; // dl@1
  BYTE v3; // bl@2
  double v4; // st7@4
  HRESULT result; // eax@8

  v2 = pdecIn->scale;
  if ( v2 > 0x1Cu || (v3 = pdecIn->sign, v3 & 0x7F) )
  {
    result = -2147024809;
  }
  else
  {
    if ( (pdecIn->Mid32 & 0x80000000u) == 0 )
      v4 = ((double)pdecIn->Hi32 * 1.844674407370955e19 + (double)*(signed __int64 *)&pdecIn->Lo32) / sub_1006AC0D(v2);
    else
      v4 = ((double)*(signed __int64 *)&pdecIn->Lo32 + 1.844674407370955e19 + (double)pdecIn->Hi32
                                                                            * 1.844674407370955e19)
         / sub_1006AC0D(v2);
    if ( v3 )
      v4 = -v4;
    *(_QWORD *)pdblOut = *(_QWORD *)&v4;
    result = 0;
  }
  return result;
}

double __fastcall sub_1006AC0D(unsigned int a1)
{
  double result; // st7@2

  if ( a1 > 0x50 )
    result = sub_1006ABD4((void *)a1, 10.0);
  else
    result = dbl_1002EF08[a1];
  return result;
}

double __thiscall sub_1006ABD4(void *this, double a2)
{
  unsigned int v2; // eax@1
  double v3; // st6@3
  double i; // st5@3
  double result; // st7@9

  v2 = (unsigned int)this;
  if ( (signed int)this < 0 )
    v2 = -(signed int)this;
  v3 = 1.0;
  for ( i = a2; ; i = i * i )
  {
    if ( v2 & 1 )
      v3 = v3 * i;
    v2 >>= 1;
    if ( !v2 )
      break;
  }
  if ( (signed int)this >= 0 )
    result = v3;
  else
    result = 1.0 / v3;
  return result;
}

.text:1002EF08 ; double dbl_1002EF08[]
.text:1002EF08 dbl_1002EF08    dq 1.0                  ; DATA XREF: VarDecFromR4:loc_1002F23Ar
.text:1002EF08                                         ; VarDecFromR8:loc_1002F4BAr ...
.text:1002EF10                 dd 0
.text:1002EF14                 dd 40240000h, 0
.text:1002EF1C                 dd 40590000h, 0
.text:1002EF24                 dd 408F4000h, 0
.text:1002EF2C                 dd 40C38800h, 0
.text:1002EF34                 dd 40F86A00h, 0
.text:1002EF3C                 dd 412E8480h, 0
.text:1002EF44                 dd 416312D0h, 0
.text:1002EF4C                 dd 4197D784h, 0
.text:1002EF54                 dd 41CDCD65h, 20000000h, 4202A05Fh, 0E8000000h, 42374876h
.text:1002EF54                 dd 0A2000000h, 426D1A94h, 0E5400000h, 42A2309Ch, 1E900000h
.text:1002EF54                 dd 42D6BCC4h, 26340000h, 430C6BF5h, 37E08000h, 4341C379h
.text:1002EF54                 dd 85D8A000h, 43763457h, 674EC800h, 43ABC16Dh, 60913D00h
.text:1002EF54                 dd 43E158E4h, 78B58C40h, 4415AF1Dh, 0D6E2EF50h, 444B1AE4h
.text:1002EF54                 dd 64DD592h, 4480F0CFh, 0C7E14AF6h, 44B52D02h, 79D99DB4h
.text:1002EF54                 dd 44EA7843h, 2C280291h, 45208B2Ah, 0B7320335h, 4554ADF4h
.text:1002EF54                 dd 0E4FE8402h, 4589D971h, 2F1F1281h, 45C027E7h, 0FAE6D721h
.text:1002EF54                 dd 45F431E0h, 39A08CEAh, 46293E59h, 8808B024h, 465F8DEFh
.text:1002EF54                 dd 0B5056E17h, 4693B8B5h, 2246C99Ch, 46C8A6E3h, 0EAD87C03h
.text:1002EF54                 dd 46FED09Bh, 72C74D82h, 47334261h, 0CF7920E3h, 476812F9h
.text:1002EF54                 dd 4357691Bh, 479E17B8h, 2A16A1B1h, 47D2CED3h, 0F49C4A1Dh
.text:1002EF54                 dd 48078287h, 0F1C35CA5h, 483D6329h, 371A19E7h, 48725DFAh
.text:1002EF54                 dd 0C4E0A061h, 48A6F578h, 0F618C879h, 48DCB2D6h, 59CF7D4Ch
.text:1002EF54                 dd 4911EFC6h, 0F0435C9Eh, 49466BB7h, 0EC5433C6h, 497C06A5h
.text:1002EF54                 dd 0B3B4A05Ch, 49B18427h, 0A0A1C873h, 49E5E531h, 8CA3A8Fh
.text:1002EF54                 dd 4A1B5E7Eh, 0C57E649Ah, 4A511B0Eh, 76DDFDC0h, 4A8561D2h
.text:1002EF54                 dd 14957D30h, 4ABABA47h, 6CDD6E3Eh, 4AF0B46Ch, 8814C9CEh
.text:1002EF54                 dd 4B24E187h, 6A19FC41h, 4B5A19E9h, 0E2503DA9h, 4B905031h
.text:1002EF54                 dd 5AE44D13h, 4BC4643Eh, 0F19D6057h, 4BF97D4Dh, 6E04B86Dh
.text:1002EF54                 dd 4C2FDCA1h, 0E4C2F344h, 4C63E9E4h, 1DF3B015h, 4C98E45Eh
.text:1002EF54                 dd 0A5709C1Bh, 4CCF1D75h, 87666191h, 4D037269h, 0E93FF9F5h
.text:1002EF54                 dd 4D384F03h, 0E38FF872h, 4D6E62C4h, 0E39FB47h, 4DA2FDBBh
.text:1002EF54                 dd 0D1C87A19h, 4DD7BD29h, 463A989Fh, 4E0DAC74h, 0ABE49F64h
.text:1002EF54                 dd 4E428BC8h, 0D6DDC73Dh, 4E772EBAh, 8C95390Ch, 4EACFA69h
.text:1002EF54                 dd 0F7DD43A7h, 4EE21C81h, 75D49491h, 4F16A3A2h, 1349B9B5h
.text:1002EF54                 dd 4F4C4C8Bh, 0EC0E1411h, 4F81AFD6h

【讨论】：

【解决方案2】：

我认为这是Convert.ToDouble(decimal d) 中的一个错误。 C# 规范说转换应该给出最接近的双精度，但这里显然没有。查看这些位，我们可以看到它偏离了两倍。

double d = 1478110092.9070129;
decimal dc = 1478110092.9070129M;
double dcd = Convert.ToDouble(dc);
long d_bits = BitConverter.DoubleToInt64Bits(d);     // 4743986451068882048
long dcd_bits = BitConverter.DoubleToInt64Bits(dcd); // 4743986451068882047

另请参阅此可能的重复项：

Conversion of a decimal to double number in C# results in a difference

【讨论】：

我做了一些挖掘，如果有的话，这是OleAut32.dll 中的一个错误。它只是将调用转发到本机函数调用。

【解决方案3】：

Double 只精确到小数点后 16 位，因此重复计算会很快累积舍入误差。小数是精确到小数点后 28 位。 Double 可以处理更大的数字，但除非您处理大型科学计算并了解任何精度损失可能对您意味着什么，否则请始终使用小数，尤其是用于货币计算。

关于this SO question有一些很好的讨论。

编辑

请参阅下面的 cmets - 我误读了问题，另一位用户 (user1666620) 在 cmets 中提供了与数字实际存储方式相关的合法答案。在Double 的情况下，这是一个无法正确表示分数的二进制表示。

【讨论】：

这并不能真正回答问题，因为在这种情况下，真正的问题是双精度数以二进制形式存储，而某些数字在二进制中没有准确的表示。
公平点，我没有仔细阅读这个问题。我责怪酒吧午餐。