blocks|key|239581|text|我的猜测是，具有浮点精度的6.2f实数表示形式是6.1999999，而62f可能类似于62.00000001。(int)强制转换总是截断十进制值，因此这就是为什么您会得到该行为。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|BOLD|entityRanges|data|239582|编辑：根据评论，我将int强制转换的行为重新定义为更精确的定义。|239583|entityMap^0|D|4|O|9|Z|3|17|B|1J|5|1U|6|0|0|2|A|3|0^^$0|@$1|2|3|4|5|6|7|K|8|@$9|L|A|M|B|C]|$9|N|A|O|B|C]|$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|D]]|E|@]|F|$]]|$1|G|3|H|5|6|7|X|8|@$9|Y|A|Z|B|D]|$9|10|A|11|B|C]]|E|@]|F|$]]|$1|I|3|-4|5|6|7|12|8|@]|E|@]|F|$]]]|J|$]]

My guess is that <code>6.2f</code> real representation with float precision is <code>6.1999999</code> while <code>62f</code> is probably something similar to <code>62.00000001</code>. <code>(int)</code> casting always truncates the decimal value so that is why you get that behavior.

EDIT: According to comments I have rephrased the behavior of <code>int</code> casting to a much more precise definition.

blocks|key|244527|text|有没有什么原因让你把类型转换成int而不是解析？|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|244528|int+speed1+=+(int)(6.2f+*+10)|code-block|syntax|javascript|244529|然后会读到|244530|int+speed1+=+Int.Parse((6.2f+*+10).ToString());+|244531|不同之处可能与舍入有关:如果强制转换为double，则可能会得到类似于61.78426的结果。|244532|请注意以下输出|244533|int+speed1+=+(int)(6.2f+*+10);//61
double+speed2+=+(6.2f+*+10);//61.9999980926514|244534|这就是为什么你会得到不同的值！|244535|entityMap^0|F|3|0|0|0|0|J|6|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|11|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|12|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|13|8|@]|D|@]|E|$I|J]]|$1|O|3|P|5|6|7|14|8|@$9|15|A|16|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|6|7|17|8|@]|D|@]|E|$]]|$1|S|3|T|5|H|7|18|8|@]|D|@]|E|$I|J]]|$1|U|3|V|5|6|7|19|8|@]|D|@]|E|$]]|$1|W|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]]|X|$]]

Is there a reason you are type casting to <code>int</code> instead of parsing? 

<pre><code>int speed1 = (int)(6.2f * 10)
</code></pre>

would then read 

<pre><code>int speed1 = Int.Parse((6.2f * 10).ToString()); 
</code></pre>

The difference is probably to do with rounding: if you cast to <code>double</code> you will probably get something like 61.78426.

Please note the following output

<pre><code>int speed1 = (int)(6.2f * 10);//61
double speed2 = (6.2f * 10);//61.9999980926514
</code></pre>

That is why you are getting different values!

blocks|key|3127080|text|首先，我假设您知道由于浮点数四舍五入(当表示为double时，它实际上是值61.99999809265137+)，6.2f+*+10不是恰好是62，并且您的问题只是关于为什么两个看似相同的计算会导致错误的值。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3127081|答案是，在使用(int)(6.2f+*+10)的情况下，您将获取double值61.99999809265137并将其截断为一个整数，结果为61。|3127082|对于float+f+=+6.2f+*+10，您将采用双精度值61.99999809265137并四舍五入到最接近的float，即62。然后将该float截断为整数，结果为62。|3127083|练习:解释以下操作序列的结果。|3127084|double+d+=+6.2f+*+10;
int+tmp2+=+(int)d;
//+evaluate+tmp2|code-block|syntax|javascript|3127085|更新:正如注释中所指出的，表达式6.2f+*+10在形式上是一个float，因为第二个参数隐式转换为float，它比隐式转换为double的转换为better。|3127086|实际的问题是编译器被允许(但不是必需的)使用中间件higher+precision+than+the+formal+type+(section+11.2.2)。这就是为什么您会在不同的系统上看到不同的行为:在expression+(int)(6.2f+*+10)中，编译器可以选择在转换为int之前将值6.2f+*+10保留为高精度的中间形式。如果是，则结果为61。如果不是，则结果为62。|3127087|在第二个示例中，对float的显式赋值强制在转换为整数之前进行舍入。|3127088|entityMap|0|LINK|mutability|MUTABLE|url|http://en.csharp-online.net/ECMA-334:_14.4.2.3_Better_conversion|1|https://www.ecma-international.org/publications/files/ECMA-ST/ECMA-334.pdf^0|N|6|1L|9|0|7|G|W|6|0|2|J|1L|5|1Z|5|0|0|0|G|9|W|5|1E|5|1R|6|21|6|0|0|37|G|40|3|47|9|P|1I|1|0|9|5|0^^$0|@$1|2|3|4|5|6|7|16|8|@$9|17|A|18|B|C]|$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1B|8|@$9|1C|A|1D|B|C]|$9|1E|A|1F|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1G|8|@$9|1H|A|1I|B|C]|$9|1J|A|1K|B|C]|$9|1L|A|1M|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1N|8|@]|D|@]|E|$]]|$1|L|3|M|5|N|7|1O|8|@]|D|@]|E|$O|P]]|$1|Q|3|R|5|6|7|1P|8|@$9|1Q|A|1R|B|C]|$9|1S|A|1T|B|C]|$9|1U|A|1V|B|C]|$9|1W|A|1X|B|C]]|D|@$9|1Y|A|1Z|1|20]]|E|$]]|$1|S|3|T|5|6|7|21|8|@$9|22|A|23|B|C]|$9|24|A|25|B|C]|$9|26|A|27|B|C]]|D|@$9|28|A|29|1|2A]]|E|$]]|$1|U|3|V|5|6|7|2B|8|@$9|2C|A|2D|B|C]]|D|@]|E|$]]|$1|W|3|-4|5|6|7|2E|8|@]|D|@]|E|$]]]|X|$Y|$5|Z|10|11|E|$12|13]]|14|$5|Z|10|11|E|$12|15]]]]

First of all, I assume that you know that <code>6.2f * 10</code> is not exactly 62 due to floating point rounding (it's actually the value 61.99999809265137 when expressed as a <code>double</code>) and that your question is only about why two seemingly identical computations result in the wrong value.

The answer is that in the case of <code>(int)(6.2f * 10)</code>, you are taking the <code>double</code> value 61.99999809265137 and truncating it to an integer, which yields 61.

In the case of <code>float f = 6.2f * 10</code>, you are taking the double value 61.99999809265137 and rounding to the nearest <code>float</code>, which is 62. You then truncate that <code>float</code> to an integer, and the result is 62.

Exercise: Explain the results of the following sequence of operations.

<pre><code>double d = 6.2f * 10;
int tmp2 = (int)d;
// evaluate tmp2
</code></pre>

Update: As noted in the comments, the expression <code>6.2f * 10</code> is formally a <code>float</code> since the second parameter has an implicit conversion to <code>float</code> which is <a href="http://en.csharp-online.net/ECMA-334:_14.4.2.3_Better_conversion" rel="noreferrer">better</a> than the implicit conversion to <code>double</code>.

The actual issue is that the compiler is permitted (but not required) to use an intermediate which is <a href="https://www.ecma-international.org/publications/files/ECMA-ST/ECMA-334.pdf" rel="noreferrer">higher precision than the formal type (section 11.2.2)</a>. That's why you see different behavior on different systems: In the expression <code>(int)(6.2f * 10)</code>, the compiler has the option of keeping the value <code>6.2f * 10</code> in a high precision intermediate form before converting to <code>int</code>. If it does, then the result is 61. If it does not, then the result is 62.

In the second example, the explicit assignment to <code>float</code> forces the rounding to take place before the conversion to integer.

blocks|key|241874|text|描述|type|unstyled|depth|inlineStyleRanges|entityRanges|data|241875|浮点数很少精确。6.2f有点像6.1999998...。如果你把它转换成一个整型，它会截断它，这个*+10结果是61。|offset|length|style|CODE|241876|查看Jon+Skeets+DoubleConverter类。有了这个类，你就可以真正将浮点数的值可视化为字符串。Double和float都是浮点数，decimal不是(它是定点数字)。|BOLD|241877|示例|241878|DoubleConverter.ToExactString((6.2f+*+10))
//+output+61.9999980926513671875|code-block|syntax|javascript|241879|更多信息|241880|241881|unordered-list-item|241882|Assert.AreEqual()+with+System.Double+getting+really+confusing|241883|What+Every+Computer+Scientist+Should+Know+About+Floating-Point+Arithmetic|241884|241885|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/8825956/assert-areequal-with-system-double-getting-really-confusing|1|http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html^0|0|8|4|F|C|0|D|F|1K|6|1R|5|1Y|3|0|0|0|0|0|0|0|1P|0|0|0|21|1|0|0^^$0|@$1|2|3|4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1C|8|@$D|1D|E|1E|F|G]|$D|1F|E|1G|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1H|8|@$D|1I|E|1J|F|G]|$D|1K|E|1L|F|G]|$D|1M|E|1N|F|G]|$D|1O|E|1P|F|J]]|9|@]|A|$]]|$1|K|3|L|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|M|3|N|5|O|7|1R|8|@]|9|@]|A|$P|Q]]|$1|R|3|S|5|6|7|1S|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|U|3|-4|5|V|7|1U|8|@]|9|@]|A|$]]|$1|W|3|X|5|V|7|1V|8|@]|9|@$D|1W|E|1X|1|1Y]]|A|$]]|$1|Y|3|Z|5|V|7|1Z|8|@]|9|@$D|20|E|21|1|22]]|A|$]]|$1|10|3|-4|5|6|7|23|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|24|8|@]|9|@]|A|$]]]|12|$13|$5|14|15|16|A|$17|18]]|19|$5|14|15|16|A|$17|1A]]]]

<h3>Description</h3>

Floating numbers a rarely exact. <code>6.2f</code> is something like <code>6.1999998...</code>. 
If you cast this to an int it will truncate it and this * 10 results in 61.

Check out Jon Skeets <code>DoubleConverter</code> class. With this class you can really visualize the value of a floating number as string. <code>Double</code> and <code>float</code> are both floating numbers, decimal is not (it is a fixed point number).

<h3>Sample</h3>

<pre><code>DoubleConverter.ToExactString((6.2f * 10))
// output 61.9999980926513671875
</code></pre>

<h3>More Information</h3>

<ul>
<li><a href="http://www.yoda.arachsys.com/csharp/DoubleConverter.cs" rel="nofollow noreferrer">Jon Skeet's DoubleConverter class</a></li>
<li><a href="https://stackoverflow.com/questions/8825956/assert-areequal-with-system-double-getting-really-confusing">Assert.AreEqual() with System.Double getting really confusing</a></li>
<li><a href="http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html" rel="nofollow noreferrer">What Every Computer Scientist Should Know About Floating-Point Arithmetic</a></li>
</ul>

blocks|key|244607|text|看看IL：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|244608|IL_0000:++ldc.i4.s++++3D++++++++++++++//+speed1+=+61
IL_0002:++stloc.0
IL_0003:++ldc.r4++++++00+00+78+42+++++//+tmp+=+62.0f
IL_0008:++stloc.1
IL_0009:++ldloc.1
IL_000A:++conv.i4
IL_000B:++stloc.2|code-block|syntax|javascript|244609|编译器将编译时常量表达式减少为它们的常量值，我认为当它将常量转换为int时，它会在某些时候进行错误的近似。在speed2的情况下，这种转换不是由编译器进行的，而是由CLR进行的，它们似乎应用了不同的规则……|offset|length|style|CODE|244610|entityMap^0|0|0|X|3|1I|6|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@$I|R|J|S|K|L]|$I|T|J|U|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

Look at the IL:

<pre><code>IL_0000: ldc.i4.s 3D // speed1 = 61
IL_0002: stloc.0
IL_0003: ldc.r4 00 00 78 42 // tmp = 62.0f
IL_0008: stloc.1
IL_0009: ldloc.1
IL_000A: conv.i4
IL_000B: stloc.2
</code></pre>

The compiler reduces compile-time constant expressions to their constant value, and I think it makes a wrong approximation at some point when it converts the constant to <code>int</code>. In the case of <code>speed2</code>, this conversion is made not by the compiler, but by the CLR, and they seem to apply different rules...

blocks|key|243200|text|Single只有7位数，在将其转换为Int32时，编译器会截断所有浮点数位。在转换过程中，可能会丢失一个或多个有效数字。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|243201|Int32+speed0+=+(Int32)(6.2f+*+100000000);+|code-block|syntax|javascript|243202|给出了619999980的结果，因此(Int32)(6.2f+*+10)得到61。|243203|当两个单数相乘时就不同了，在这种情况下没有截断操作，只有近似值。|243204|请参阅http://msdn.microsoft.com/en-us/library/system.single.aspx|243205|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/system.single.aspx^0|0|6|I|5|0|0|0|0|3|1M|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]|$9|11|A|12|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|13|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|14|8|@]|D|@]|E|$]]|$1|M|3|N|5|6|7|15|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|16|8|@]|D|@$9|17|A|18|1|19]]|E|$]]|$1|Q|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]]|R|$S|$5|T|U|V|E|$W|X]]]]

<code>Single</code> mantains only 7 digits and when casting it to a <code>Int32</code> the compiler truncate all the floating point digits. During conversion one or more significant digits could be lost.

<pre><code>Int32 speed0 = (Int32)(6.2f * 100000000); 
</code></pre>

gives the result of 619999980 so (Int32)(6.2f * 10) gives 61.

It's different when two Single are multiplied, in that case there is no truncate operation but only approximation. 

See <a href="http://msdn.microsoft.com/en-us/library/system.single.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/library/system.single.aspx</a>

blocks|key|244631|text|我编译并反汇编了这段代码(在Win7/.NET+4.0上)。我猜编译器会将浮点常量表达式计算为双精度。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|244632|int+speed1+=+(int)(6.2f+*+10);
+++mov+++++++++dword+ptr+[rbp%2B8],3Dh+++++++//result+is+precalculated+(61)

float+tmp+=+6.2f+*+10;
+++movss+++++++xmm0,dword+ptr+[000004E8h]++//precalculated+(float+format,+xmm0=0x42780000+(62.0))
+++movss+++++++dword+ptr+[rbp%2B0Ch],xmm0+

int+speed2+=+(int)tmp;
+++cvttss2si+++eax,dword+ptr+[rbp%2B0Ch]+++++//instrunction+converts+float+to+Int32+(eax=62)
+++mov+++++++++dword+ptr+[rbp%2B10h],eax+|code-block|syntax|javascript|244633|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

I compiled and disassembled this code (on Win7/.NET 4.0).
I guess that compiler evaluates floating constant expression as double.

<pre><code>int speed1 = (int)(6.2f * 10);
 mov dword ptr [rbp+8],3Dh //result is precalculated (61)

float tmp = 6.2f * 10;
 movss xmm0,dword ptr [000004E8h] //precalculated (float format, xmm0=0x42780000 (62.0))
 movss dword ptr [rbp+0Ch],xmm0 

int speed2 = (int)tmp;
 cvttss2si eax,dword ptr [rbp+0Ch] //instrunction converts float to Int32 (eax=62)
 mov dword ptr [rbp+10h],eax 
</code></pre>

I have the following simple code : 

<pre><code>int speed1 = (int)(6.2f * 10);
float tmp = 6.2f * 10;
int speed2 = (int)tmp;
</code></pre>

<code>speed1</code> and <code>speed2</code> should have the same value, but in fact, I have :

<pre><code>speed1 = 61
speed2 = 62
</code></pre>

I know I should probably use Math.Round instead of casting, but I'd like to understand why the values are different.

I looked at the generated bytecode, but except a store and a load, the opcodes are the same.

I also tried the same code in java, and I correctly obtain 62 and 62.

Can someone explain this ?

Edit : 
In the real code, it's not directly 6.2f * 10 but a function call * a constant. I have the following bytecode :

for <code>speed1</code> : 

<pre><code>IL_01b3: ldloc.s V_8
IL_01b5: callvirt instance float32 myPackage.MyClass::getSpeed()
IL_01ba: ldc.r4 10.
IL_01bf: mul
IL_01c0: conv.i4
IL_01c1: stloc.s V_9
</code></pre>

for <code>speed2</code> : 

<pre><code>IL_01c3: ldloc.s V_8
IL_01c5: callvirt instance float32 myPackage.MyClass::getSpeed()
IL_01ca: ldc.r4 10.
IL_01cf: mul
IL_01d0: stloc.s V_10
IL_01d2: ldloc.s V_10
IL_01d4: conv.i4
IL_01d5: stloc.s V_11
</code></pre>

we can see that operands are floats and that the only difference is the <code>stloc/ldloc</code>.

As for the virtual machine, I tried with Mono/Win7, Mono/MacOS, and .NET/Windows, with the same results.

C# Float expression: strange behavior when casting the result float to int

我有以下简单的代码：int speed1 = (int)(6.2f * 10);float tmp = 6.2f * 10;int speed2 = (int)tmp;speed1和speed2应该有相同的值，但实际上，我有：speed1 = 61speed2 = 62我知道我可能应该使用Math.Round而不是强制...

问C#浮点表达式:将结果浮点转换为整型时的奇怪行为
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C#浮点表达式:将结果浮点转换为整型时的奇怪行为EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C#浮点表达式:将结果浮点转换为整型时的奇怪行为
EN