.NET C# float.Parse 将不同的结果返回给 double.Parse [重复]

Question

能否请一些更有经验的人解释一下我今天发现的这个奇怪的错误？ 当我用我的 C# 脚本加载表数据时，我得到了奇怪的数量。

事实证明，问题在于类似函数的输出不同：

string amount_in_string = "1234567,15";
double amount_in_double = double.Parse(amount_in_string);
float amount_in_float = float.Parse(amount_in_string);

//amount_in_double = 1234567.15;
//amount_in_float = 1234567.13;

当 float 和 double 是相似类型（浮点）时，为什么我会得到如此不同的结果。像这样少量的精度可以产生影响吗？

Answer 1

当“1234567.15”转换为double时，结果是double中可表示的最接近的值，即1234567.1499999999068677425384521484375。尽管您在问题中报告该值为 1234567.15，但实际值为 1234567.1499999999068677425384521484375。当数值以有限的小数位数显示时，将显示“1234567.15”。

当“1234567.15”转换为float时，结果是float中可表示的closet值，即1234567.125。虽然您报告的值为 1234567.13，但实际值为 1234567.125。当值显示的小数位数有限时，可能会显示“1234567.13”。

---

观察到 1234567 超过了 1,048,576，即 2²⁰。用于float 的 32 位浮点格式使用 24 位作为有效数（数字的小数部分）。如果有效数字的高位表示2²⁰，则低位表示2²⁰⁻²³ = 2^-3 = ⅛。这就是为什么您会看到“1234567.15”转换为四舍五入到最接近八分之一的值。

Answer 2

浮点数从来都不是精确的，它们是数字的表示。一个常用的例子是想想

1/3 + 1/3 = 2/3

...所以浮点数的答案 .33333 + .33333 不是精确的 2/3，而是 .66666。

长话短说，无法转换为精确二进制的更精确分数将始终具有舍入数。越精确，就越有可能出现舍入误差。

请记住，如果您使用多个不同的分数，您甚至可能会出现多个不同的舍入错误，这些错误会导致数字意外正确，甚至更远。

Answer 3

你可以看到结果的小提琴（这里也有文化问题）

https://dotnetfiddle.net/Lnv1q7

    string amount_in_string = "1234567,15"; // NOTE THE COMMA in original
    string amount_in_string = "1234567.15"; //my correct culture
    double amount_in_double = double.Parse(amount_in_string);
    float amount_in_float = float.Parse(amount_in_string);

    Console.WriteLine(amount_in_string);
    Console.WriteLine(amount_in_double);
    Console.WriteLine(amount_in_float);

结果（在不正确的文化中解析！）

1234567,15
123456715
1.234567E+08

结果（以正确的文化解析！）

1234567.15
1234567.15
1234567

另一个用float 证明精度损失

float flt = 1F/3;
double dbl = 1D/3;
decimal dcm = 1M/3;
Console.WriteLine("float: {0} double: {1} decimal: {2}", flt, dbl, dcm);

结果

float: 0.3333333  
double: 0.333333333333333  
decimal: 0.3333333333333333333333333333

浮点数只应在精度损失不是非常有价值的情况下使用。这是因为浮点数是 32 位，十进制是 128 位 浮点数主要用于像素坐标，精度损失无关紧要，因为消费者会以任何方式将位置转换为更精确的坐标。

“应该”积极避免在 .NET 中浮动，除非您不关心（某些）精度的损失。现在可能永远不会有这样的日子（除非你写游戏）

这就是银行问题的由来，当交易中有 100 美分/美分丢失时，每笔交易看似不可见，但相当于大量“丢​​失”的钱。

使用小数