为什么除法结果会根据强制转换类型而有所不同？ （跟进）

这是这个问题的后续：为什么除法结果会根据强制转换类型而有所不同？ https://stackoverflow.com/questions/25703304/why-does-a-division-result-differ-based-on-the-cast-type

快速总结：

byte b1 = (byte)(64 / 0.8f); // b1 is 79
int b2 = (int)(64 / 0.8f); // b2 is 79
float fl = (64 / 0.8f); // fl is 80

问题是：为什么根据演员类型的不同结果会有所不同？在寻找答案时，我遇到了一个无法解释的问题。

var bytes = BitConverter.GetBytes(64 / 0.8f).Reverse(); // Reverse endianness
var bits = bytes.Select(b => Convert.ToString(b, 2).PadLeft(8, '0'));
Console.WriteLine(string.Join(" ", bits));

这会输出以下内容：

01000010 10100000 00000000 00000000

将其分解为 IEEE 754 格式：

0 10000101 01000000000000000000000

Sign:

0 => Positive

指数：

10000101 => 133 in base 10

尾数：

01000000000000000000000 => 0*2^-1 + 1*2^-2 + 0*2^-3 ... = 1/4 = 0.25

十进制表示法：

(1 + 0.25) * 2^(133 - 127) (Subtract single precision bias)

结果正好是 80。那么为什么转换结果会产生不同呢？

我在另一个线程中的回答并不完全正确：实际上，在运行时计算时，(byte)(64 / 0.8f) is 80.罢工>

当施放一个float包含结果64 / 0.8f, to byte在运行时，结果实际上是 80。但是，当转换作为赋值的一部分完成时，情况并非如此：

float f1 = (64 / 0.8f);

byte b1 = (byte) f1;
byte b2 = (byte)(64 / 0.8f);

Console.WriteLine(b1); //80
Console.WriteLine(b2); //79

虽然 b1 包含预期结果，但 b2 关闭。根据反汇编，b2 的赋值如下：

mov         dword ptr [ebp-48h],4Fh 

因此，编译器计算出的结果似乎与运行时的结果不同。但是，我不知道这是否是预期的行为。

EDIT：也许这就是 Pascal Cuoq 所描述的效果：在编译时，C# 编译器使用double来计算表达式。这会导致 79,xxx 被截断为 79（因为双精度数包含足够的精度，因此会导致问题）。
然而，使用浮点数，我们实际上并没有遇到问题，因为浮点“错误”发生在浮点数的范围内。

在运行时，这个也打印 79：

double d1 = (64 / 0.8f);
byte b3 = (byte) d1;
Console.WriteLine(b3); //79

EDIT2:根据 Pascal Cuoq 的要求，我运行了以下代码：

int sixtyfour = Int32.Parse("64");
byte b4 = (byte)(sixtyfour / 0.8f);
Console.WriteLine(b4); //79

结果是79。所以上面所说的编译器和运行时计算出不同结果的说法是不正确的。

EDIT3：将之前的代码更改为（再次归功于 Pascal Cuoq）时，结果为 80：

byte b5 = (byte)(float)(sixtyfour / 0.8f);
Console.WriteLine(b5); //80

但请注意，写入时情况并非如此（结果为 79）：

byte b6 = (byte)(float)(64 / 0.8f);
Console.WriteLine(b6); //79

所以这似乎是发生的事情：(byte)(64 / 0.8f)不被评价为float，但评估为double（在将其投射到byte）。这会导致舍入误差（当使用以下方法完成计算时不会发生舍入误差）float）。在转换为 double 之前显式转换为 float（顺便说一句，这被 ReSharper 标记为多余）“解决”了这个问题。但是，当计算在编译时完成时（仅使用常量时可能），显式转换为float似乎被忽略/优化掉了。

TLDR：浮点计算比最初看起来更复杂。