为什么 .NET 不定义更小的 Decimal 类型？答案

【问题标题】：Why doesn't .NET define smaller Decimal types?为什么 .NET 不定义更小的 Decimal 类型？
【发布时间】：2012-03-22 16:23:04
【问题描述】：

所以我（想我）理解Float, Double, and Decimal 之间的区别，但我想知道的一件事是为什么有两种大小的浮点二进制点，但只有一种大小的浮点小数点？

如果我正确理解了一般原则，如果您不需要额外的大小，您可能希望在 32 位处理器上使用浮点数（32 位）以获得双倍（64 位）的性能双的。在 64 位处理器上，双精度应该更高性能，所以这个理由不是必需的。但是 Decimal 类型是 128 位。那么为什么不提供 64 位十进制，甚至 32 位呢？

这只是用例的问题吗？没有人真正需要它吗？还是有技术原因，比如您无法准确呈现小于 128 位的有用十进制范围？

【问题讨论】：

为什么单精度浮点数比双精度浮点数快？内存总线在任何情况下都是 64 位宽的，如今许多 CPU 都有独立的 FPU，这些 FPU 具有足够大的寄存器（x86 有 80 位浮点数！），内部布线的任何速度差异都应该很小（可能小于一个机器周期）。更好的理由是内存大小，即便如此，您也需要数百万个数字才能有所作为。
@delnan 浮点/双倍分界线是几十年前创建的，当时计算硬件非常不同。还要考虑像 SSE 这样的 SIMD 操作可以推送两倍于双倍的浮点数。
@DavidHeffernan 确实如此。我完全意识到这一点，但 OP 显然认为今天存在类似的差异。因此我的评论。 SIMD 的优点在于，虽然这超出了大多数人关心的优化水平。
@delnan 仍然存在 SIMD 差异
我不知道硬件中可能存在或仍然存在哪些区别，因此感谢您的启发性讨论。

标签： .net floating-point

【解决方案1】：

Eric Lippert 的Features start off as unimplemented and only become implemented when people spend effort implementing them 的必填链接。

为什么这不是个好主意：

任何额外的数字类型都需要从 / 到其他数字类型的大量转换，以及允许和不允许的规则。
较小的类型（尤其是 32 位）根本没有有用的范围 - 即商品的合理价格范围至少为 8 位 12345.67（最低货币单位的十分之一）。

【讨论】：

虽然我完全理解 Lippert 文章背后的情感，但我并不认为“因为没有人愿意这样做”是任何人真正想要回答的这类问题。我认为他也知道这一点，因为他继续解释了他们没有实现该功能的原因。同样，感谢您确认我认为 32 位或 64 位十进制类型可能太小而无法真正使用，因此可能不值得实施。

【解决方案2】：

较小的十进制类型的能力会降低。由于您不倾向于执行与浮点数据常见的相同类型的大容量计算，因此出于性能考虑，似乎不需要较小的小数。

【讨论】：

【解决方案3】：

为什么有两种大小的浮点二进制点

因为许多编程语言已经具有单独的单精度和双精度浮点类型，包括 C(++)、Java 和 Visual Basic。所以很自然，C++/CLI、J# 和 VB.NET 也会有这些类型。

OTOH，有多个十进制浮点类型没有向后兼容的原因。

如果我正确理解了一般原则，您会想使用浮点（32 位）在 32 位上的双倍（64 位）性能处理器，如果您不需要双倍的额外大小。

没有。尽管有它的名字，double 长期以来一直是“主要”浮点类型，而float 是用于内存优化的“半精度”类型。例如，.NET System.Math 类几乎总是使用double 而不是float。而且在所有 C 派生语言中，像 1.23 这样的文字都有 double 类型（您需要额外的 f 才能获得浮点数）。

那么为什么不提供 64 位十进制，甚至 32 位呢？

使用 32 位（可能是 7 位）decimal，您总是会遇到舍入错误。现在，可能存在您为了效率而刻意牺牲精度的情况，但在这种情况下，您不妨使用float 来获得硬件支持的好处。

【讨论】：