问题描述
我正在考虑为BigDecimal编写两个有限精度的替代方法，即DecimalInt和DecimalLong.它们将能够处理int和long实数范围内的数字，并且可以以可变形式和不可变形式创建任意数量的小数位.我的计划是使DecimalInt支持+/- 999,999,999到+/- 0.999999999和DecimalLong相同，但最多支持18位数字.
I am considering writing two limited precision alternatives to BigDecimal, namely DecimalInt and DecimalLong. These would be capable of dealing with numbers within the real bounds of int and long with an arbitrary number of decimal places, creatable in both mutable and immutable form. My plan is to make DecimalInt support +/-999,999,999 to +/- 0.999999999 and DecimalLong the same, but with up to 18 digits.
这可以通过将DecimalInt保持为0-9的十进制数字计数值以及DecimalLong保持为0-18的十进制数字计数值以及存储为缩放的int或long的实际值来实现.正常使用情况是使用少量的小数，例如货币和股票价格，通常是2-4个小数位.
This would be done by maintaining a decimal digit count value of 0-9 for DecimalInt and 0-18 for DecimalLong along side the actual value stored as a scaled int or long. The normal use would be for small numbers of decimals such as for money and stock prices, typically 2-4 decimal places.
基本要求是(a)精简版图(2个类，再加上OverflowException)，以及(b)全面支持所有基本操作以及所有有意义的数学.
The essential requirements are (a) lean footprint (2 classes, plus OverflowException), and (b) full support of all basic operations plus all of Math that makes sense.
Google搜索结果未返回任何明显的匹配-它们似乎都与任意小数有关.
Googling for results did not return any obvious hits - they all seemed to pertain to arbitrary decimals.
我的问题是:这已经完成了吗?这有没有隐藏的微妙之处，这就是为什么它还没有完成呢?有没有人听说过Java支持像DotNet这样的十进制类型的传闻.
My questions are: Has this already been done? Are there hidden subtleties in this which is why it has not already been done? Has anyone heard rumors of Java supporting a decimal type like DotNet's.
这与BigDecimal不同，因为它应该(a)更有效地处理一个int数组，并且(b)它不会包装BigInteger，因此它在内存上更精简(c)它也将具有可变选项，因此在那里也会更快.总结-对于我想存储银行余额而不需要BigDecimal的开销和double的不准确性"这样的简单用例，开销会更少.
This is different from BigDecimal because it should be (a) a hell of a lot more efficient to not deal with an array of ints, and (b) it won't wrap BigInteger so it will be leaner on memory too, and (c) it will have a mutable option so it will be faster there as well. In summary - less overhead for the simple use cases like "I want to store a bank balance without the overhead of BigDecimal and the inaccuracy of double".
我打算使用int或long进行所有数学运算，以避免出现经典问题:1586.60-708.75 = 877.8499999999999而不是877.85
I intend on doing all the math using int or long to avoid the classic problem of: 1586.60-708.75=877.8499999999999 instead of 877.85
推荐答案
我强烈怀疑未完成此操作的原因是BigDecimal和BigInteger的开销不如您想象的那样重要，因此避免这样做不值得努力和以某种微妙的方式将其弄错的风险.
I strongly suspect the reason why this has not been done is that the overhead of BigDecimal and BigInteger is not as relevant as you think, and avoiding it not worth the effort and the risk of getting it wrong in some subtle way.
以您的示例为例:对于任何金融应用程序而言，节省几十个字节都是不成问题的，并且精度有限，这会破坏交易(在美国，股票价格通常为2-4位，但是如果您要交易，在新兴市场中，您会遇到通货膨胀失控的货币，其中15位数字的总和能为您带来半面包.
To use your example: for any financial application, saving a few dozen bytes is a non-issue and limited precision a deal-breaker (stock prices my have typically 2-4 digits in the USA, but if you want to deal with emerging markets, you'll encounter currencies with runaway inflation, where a 15-digit sum buys you half a loaf of bread).
基本上，这听起来像是过早优化的另一种情况.
Basically, it sounds like just another case of premature optimization.
这篇关于轻量级Java十进制类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！