decimal.Round 的奇怪行为答案

【问题标题】：Weird behaviour of decimal.Rounddecimal.Round 的奇怪行为
【发布时间】：2018-09-11 13:58:47
【问题描述】：

使用decimal时，为什么舍入的行为总是一样的？

无论我是否使用MidpointRounding.AwayFromZero，它总是给出1.04。第一种情况，输出不应该是1.03吗？

Console.WriteLine(decimal.Round(1.035m, 2));
Console.WriteLine(decimal.Round(1.035m, 2, MidpointRounding.AwayFromZero));

https://github.com/dotnet/corefx/blob/664d98b3dc83a56e1e6454591c585cc6a8e19b78/src/Common/src/CoreLib/System/Decimal.cs#L612

https://github.com/dotnet/corefx/blob/61d792e202d039c304c4f04ad816a57688f32fd4/src/Common/src/CoreLib/System/Decimal.DecCalc.cs#L2429-L2444

【问题讨论】：

docs 包含一个有用的表格，说明ToEven 和AwayFromZero 的结果何时相同（何时不同）。要四舍五入到1.03，它需要向零四舍五入，而Round 没有实现。（Truncate 可以，但没有小数参数。）
@JeroenMostert 我现在明白了，MidpointRounding.ToEven 将始终尝试四舍五入，所以在 2.5 的情况下，它将是 2，因为 2 是偶数，而不是 3，因为 3 不是甚至。

标签： c# .net-core coreclr

【解决方案1】：

No:

此方法 [Round(decimal d, int decimals)] 等价于使用模式参数 MidpointRounding.ToEven 调用 Round(Decimal, Int32, MidpointRounding) 方法。

当 d 正好在两个舍入值的中间时，结果是舍入后的值，小数点最右边有一个偶数位。例如，当四舍五入到两位小数时，值 2.345 变为 2.34，值 2.355 变为 2.36。

所以当将1.035 舍入为偶数时，它变为1.04，因为 4 是偶数而 3 不是。

【讨论】：

【解决方案2】：

默认舍入方式为MidpointRounding.ToEven，所以在选择是否舍入到1.03或1.04时，会选择末尾为偶数的1.04。

【讨论】：

【解决方案3】：

正如MSDN所说：

public static decimal Round(
    decimal d,
    int decimals
)

decimals : 一个从 0 到 28 的值，用于指定小数位数四舍五入。

你想在 2 个地方四舍五入，它必须是 1.04

【讨论】：

【解决方案4】：

在四舍五入时，这似乎是我的预期行为。

例如：

1.035 => 1.040 产生两位小数 1.04

1.033 => 1.030 产生两位小数 1.03

【讨论】：

【解决方案5】：

默认四舍五入不是四舍五入吗？在这种情况下，5 被四舍五入并结转......

默认情况下，Round 方法使用四舍五入到最接近的约定。下表列出了 Round 方法的重载和每个使用的舍入约定。 https://docs.microsoft.com/en-us/dotnet/api/system.math.round?view=netframework-4.7.2

【讨论】：