Getting the wrong answer

The fact is that float / double in C # (as well as in Java, C ++, etc.) are binary fractions . They are represented internally as a set of integer (mantissa) and a power of two (of order). The number 2 can be represented as a binary fraction, but 0.02 is not, since it is equal to 1/50 (and in the denominator not only powers of two). Therefore, the number 0.02 cannot be exactly represented as a float .

What is contained in the variable engine.power ? It contains the binary fraction closest to 0.02. Check it with this code:

 float enginepower = 2f / 100; Console.WriteLine(enginepower * 100 - 2); 

It gives out not 0, as one would expect, but -4.470348E-08 (on my machine).

This means that the engine.power value engine.power actually a little less than two. When multiplying by 1000, the result will be slightly less than 20, the cast to int drop the fractional part, and the result will be equal to 19.

What to do? There are several options.

1. Instead of dropping a fractional part unstable to small errors

    (int)(engine.power * 1000) 

   use much more robust rounding :

    (int)Math.Round(engine.power * 1000) 

2. If you encounter similar problems often, it makes sense to switch to the decimal data type, in which the numbers inside are stored as decimal , not binary fractions. Note that operations with this data type are slower, since there is no native support for processors.

Advanced investigation , with digging in assembly exhaust and specifications.

On my machine, this is the code:

 float f = 0.02f; float ff = f * 1000; int k = (int)(ff); 

calculates a k value of 20, and here it is:

 float f = 0.02f; int k = (int)(f * 1000); 

- 19. (This is in Debug mode; in Release mode, both versions of the text produce the same assembly code and the same result - 19.) Investigate why this is so.

The assembled JIT code is as follows:

  ; float f = 0.02f; mov dword ptr [ebp-40h],3CA3D70Ah ; 32bit f = 0.02f ; float ff = f * 1000; fld dword ptr [ebp-40h] ; extend f to 80bit prec and push fmul dword ptr ds:[1453D00h] ; multiply by 32bit 1000f fstp dword ptr [ebp-44h] ; pop and convert 80bit result to 32 bit -> ff ; int k = (int)(ff); fld dword ptr [ebp-44h] ; extend ff to 80bit prec and push fstp qword ptr [ebp-50h] ; pop and convert to 64bit -> double temp movsd xmm0,mmword ptr [ebp-50h] ; extend temp to 128bit and copy to xmm0 cvttsd2si eax,xmm0 ; truncate to 32bit int eax mov dword ptr [ebp-48h],eax ; store to k 

and

  ; float f = 0.02f; mov dword ptr [ebp-40h],3CA3D70Ah ; 32bit f = 0.02f ; int k = (int)(f * 1000); fld dword ptr [ebp-40h] ; extend f to 80bit prec and push fmul dword ptr ds:[1393CF4h] ; multiply by 32bit 1000f fstp qword ptr [ebp-4Ch] ; pop and convert to 64bit -> double temp movsd xmm0,mmword ptr [ebp-4Ch] ; extend temp to 128bit and copy to xmm0 cvttsd2si eax,xmm0 ; truncate to 32bit int eax mov dword ptr [ebp-44h],eax ; store to k 

This can be conventionally written as:

 float32 f = 2f / 100; float80 r1 = f; r1 *= float32(1000f); float32 ff = r1; r1 = ff; // <-- тут потеря точности float64 temp = r1; float128 r2 = temp; int32 k = (int32)r2; 

and

 float32 f = 2f / 100; float80 r1 = f; r1 *= float32(1000f); float64 temp = r1; float128 r2 = temp; int32 k = (int32)r2; 

The difference, as we see, is that for calculating an intermediate result, the value of f * 1000 is truncated to 32-bit precision, and then loaded back into the 80-bit register, and from there through the 64-bit value is loaded into the XMM register. In the second variant of the code, the intermediate result is not stored, the code does not trim the value, and a more accurate 80-bit value is trimmed to 64 bits, which leads to a difference in the result.

Explicit permission for such different computation paths is in the language specification, §4.1.6 Floating Point Types:

Than the result of the operation. For example, it can be noted that it can be used for example.

More on the topic: Strange behavior when casting a float to int in C # (especially the top answer).