.NET Core 3 在舍入接近 0 的负数时返回 -0 字符串

Tro*_*ald 5 .net c# .net-core

所以这种奇怪的行为是在我们正在实施的单元测试中被发现的。

在 .NET Core 3.x 中,如果将接近 0 的负数四舍五入然后转换为字符串,则该字符串将显示“-0”而不是 0。

Framework 和 .NET Core 2.x 不会表现出这种行为。

double d = -.1;
Console.WriteLine(Math.Round(d,0));
Run Code Online (Sandbox Code Playgroud)

.NET 核心小提琴

框架小提琴

这是 Core 中的一个新错误,还是一些奇怪的有意更改?

dxi*_*xiv 7

这是 .NET Core 3.0 中的一项重大更改,以确保语言和 IEEE-754 合规性之间的一致性。

引用.NET Core 3.0 中浮点解析和格式化的改进

ToString()、ToString("G") 和 ToString("R") 现在将返回最短的往返字符串。

上面的重点是“往返”。在此更改之前,负零“-0”没有正确往返,这是通过修复双/单解析代码正确#20707单/双的往返字符串格式不往返 -0的组合修复的#9883

  • @viveknuna从某种意义上说,是的,但在浮点数学中`1 / 0.0 = ∞`而`1 / -0.0 = -∞`。这实际上就是最后一个链接中给出的示例。有关更多信息,请参阅[有符号零](https://en.wikipedia.org/wiki/Signed_zero)和[IEEE-754](https://en.wikipedia.org/wiki/IEEE_754-1985)。 (7认同)
  • @Tronald 是的,而且这可能会让那些抱怨旧行为的其他人感到高兴。对于重大变更来说这是不可避免的。至于影响有多大,我不知道,也无法猜测。你的问题似乎是 SO 上关于它的第一个问题,如果这有任何迹象的话,而且距离 Core 3 预览已经一年多了。 (3认同)
  • 有件事告诉我这会吸引很多人。考虑到 .NET 已经存在了多久,我觉得如果没有一个简单的方法来覆盖就可以进行这样的更改,这有点糟糕。这将使移植现有代码成为一场噩梦,因为应用程序用户现在可能会面临到处都是 -0 的情况。 (2认同)