我有一个时间计算器,已经相当好地工作了好几年了。然而,有一件事一直困扰着我,那就是如果使用小数秒,结果将成为浮点“错误”的牺牲品。所以,我最近改用了this BigDecimal library。
现在,我得到了数学错误。这是我今天收到的bug报告中的一个简化测试用例:27436 / 30418返回的是1,而不是预期的0.9019659412190151。
为了说明我的问题,这里有一个Chrome中的Javascript控制台会话:
> first = 27436
27436
> second = 30418
30418
> first / second
0.9019659412190151 // expected result, but using JS numbers, not BigDecimals
> firstB = new BigDecimal(first.toString())
o
> secondB = new BigDecimal(second.toString())
o
> firstB / secondB
0.9019659412190151 // this is a JS number, not a BigDecimal, so it's susceptible to the problems associated with floating-point.
> firstB.divide(secondB)
o // BigDecimal object
> firstB.divide(secondB).toString()
"1" // huh? Why 1?
> firstB.divideInteger(secondB).toString()
"0"如您所见,divide()方法没有产生我期望的结果。我需要做些什么不同的事情?
更新
以下是针对这些评论的更多细节。
首先,一些人认为使用BigDecimal有点过头了。这可能是,但我认为在做出决定之前有必要提供更多细节。这个应用程序是一个time calculator,所以有几件事促使我切换到BigDecimal。首先,因为这是一个计算器,所以向用户显示正确的答案是很重要的。如果用户输入0.1 s + 0.2 s,他们期望的答案是0.3 s,而不是Javascript将显示给他们的答案(0.30000000000000004)。
我真的不想限制精度超过我可以在JS中使用的精度,因为我不知道我的用户需要的最大精度。我认为,大多数人从不使用小数秒,但从我收到的电子邮件来看,有些人确实使用了。我目前在内部以秒的形式存储所有时间。
有人建议我将数字存储为精确的分数。不幸的是,我不知道这是什么意思。也许是因为我对数学了解不多。我对创建自己的数学库知之甚少;这就是我使用BigDecimal的原因。它已经存在很长一段时间了,所以我很犹豫地说我的问题是由于BigDecimal中的一个bug。相反,我怀疑这是我使用它的方式中的一个bug。
最后,我并不是特别喜欢BigDecimal。我对其他建议持开放态度,前提是我可以用我有限的数学技能来使用它们。
发布于 2012-01-06 23:02:07
我还没有在任何产品代码中使用过BigDecimal,但我发现这个问题很有趣,所以我想试一试。您是对的,需要一个MathContext作为除法函数的参数。以下是我基于您的示例所做的工作:
console.log(firstB.divide(secondB, new MathContext(100)).toString());创建一个上下文,告诉BigDecimal在科学模式下使用100位数字输出:
0.9019659412190150568742192123085015451377473864159379314879347754618975606548754027220724570977710566也有选项来控制不同的输出模式PLAIN,SCIENTIFIC和ENGINEERING +各种舍入模式。
jsfiddle上的完整示例
更新:默认输出格式为SCIENTIFIC,而不是PLAIN。示例here
更新2:创建了一个小型的性能测试here,看起来BigDecimal比原生javascript部门慢10000倍。
https://stackoverflow.com/questions/8737489
复制相似问题