我可以说出使用double(或float)而不是decimal的三个优点:

使用较少的内存。 更快是因为浮点数学运算是由处理器原生支持的。 可以表示更大范围的数字。

但这些优势似乎只适用于计算密集型操作,比如在建模软件中发现的那些操作。当然,当需要精度时,不应该使用双精度,例如财务计算。那么,在“正常”应用程序中选择双位数(或浮点数)而不是十进制有什么实际的原因吗?

编辑补充: 谢谢你们的回复,我从他们身上学到了很多。

还有一个问题:一些人认为双数可以更精确地表示实数。当我宣布时,我认为他们通常更准确地代表他们。但是,当执行浮点运算时,精度可能会降低(有时会显著降低),这是真的吗?


当前回答

Decimal具有更宽的字节,CPU原生支持double。十进制是以10为基数的,所以在计算十进制时发生了十进制到双精度的转换。

For accounting - decimal
For finance - double
For heavy computation - double

请记住。net CLR只支持Math.Pow(double,double)。不支持十进制。

.NET Framework 4

[SecuritySafeCritical]
public static extern double Pow(double x, double y);

其他回答

像其他人建议的那样,以10为基数的值使用十进制,例如财务计算。

但是对于任意的计算值,double通常更准确。

例如,如果你想计算投资组合中每一行的权重,使用double,因为结果加起来更接近100%。

在下面的例子中,doubleResult比decimalResult更接近1:

// Add one third + one third + one third with decimal
decimal decimalValue = 1M / 3M;
decimal decimalResult = decimalValue + decimalValue + decimalValue;
// Add one third + one third + one third with double
double doubleValue = 1D / 3D;
double doubleResult = doubleValue + doubleValue + doubleValue;

还是以投资组合为例:

投资组合中每一行的市场价值都是一种货币价值,可能最好用十进制表示。 投资组合中每一行的权重(=市场价值/ SUM(市场价值))通常用双数表示更好。

默认情况下,如果科学计数法小于十进制显示,则双精度值将序列化为科学计数法。(例如,.00000003将是3e-8)十进制值将永远不会序列化为科学计数法。当序列化供外部方使用时,可能需要考虑这一点。

选择应用程序的功能类型。如果你需要像财务分析那样的精确性,那么你已经回答了你的问题。但如果你的申请可以解决一个估计,你可以接受双倍。

你的申请需要快速计算还是他有足够的时间给你答案?这取决于应用程序的类型。

图形饿了吗?Float或double就足够了。金融数据分析,流星撞击行星的精准度如何?这些都需要一点精确度:)

在某些会计中,考虑使用整型代替或结合使用整型的可能性。例如,假设您操作的规则要求每个计算结果至少前移6位,最终结果将四舍五入到最接近的便士。

A calculation of 1/6th of $100 yields $16.66666666666666..., so the value carried forth in a worksheet will be $16.666667. Both double and decimal should yield that result accurately to 6 decimal places. However, we can avoid any cumulative error by carrying the result forward as an integer 16666667. Each subsequent calculation can be made with the same precision and carried forward similarly. Continuing the example, I calculate Texas sales tax on that amount (16666667 * .0825 = 1375000). Adding the two (it's a short worksheet) 1666667 + 1375000 = 18041667. Moving the decimal point back in gives us 18.041667, or $18.04.

虽然这个简短的示例不会产生使用双位数或小数的累积错误,但可以很容易地展示简单地计算双位数或小数并继续计算会累积重大错误的情况。如果您的操作规则需要有限的小数位数,则将每个值存储为整数,通过乘以10^(所需的小数位数),然后除以10^(所需的小数位数)来获得实际值,将避免任何累积错误。

在不出现小数的情况下(例如,自动售货机),根本没有理由使用非整型。简单地把它想象成数便士,而不是数美元。我曾见过一些代码,其中每次计算都只涉及整个便士,但使用double会导致错误!只有整数数学解决了这个问题。所以我非传统的回答是,如果可能的话,放弃双位数和小数点。

如果你更看重性能而不是正确性,请使用浮点数。