摘要:除法的精度问题在使用的除法时,遇到一个鬼畜的问题,本以为的精度计算,结果使用返回,当然最终发现还是自己的使用姿势不对导致的,因此记录一下,避免后面重蹈覆辙问题抛出在使用做高精度的除法时,一不注意遇到了一个小问题,如下上面的输出是什么
BigDecimal除法的精度问题
在使用BigDecimal的除法时,遇到一个鬼畜的问题,本以为的精度计算,结果使用返回0,当然最终发现还是自己的使用姿势不对导致的,因此记录一下,避免后面重蹈覆辙
I. 问题抛出在使用BigDecimal做高精度的除法时,一不注意遇到了一个小问题,如下
@Test public void testBigDecimal() { BigDecimal origin = new BigDecimal(541253); BigDecimal now = new BigDecimal(12389431); BigDecimal val = origin.divide(now, RoundingMode.HALF_UP); System.out.println(val); origin = new BigDecimal(541253); now = new BigDecimal(12389431.3); val = origin.divide(now, RoundingMode.HALF_UP); System.out.println(val); origin = new BigDecimal(541253.4); now = new BigDecimal(12389431); val = origin.divide(now, RoundingMode.HALF_UP); System.out.println(val); }
上面的输出是什么 ?
0 0 0.043686703610520937021487456961257
为什么前面两个会是0呢,如果直接是 541253 / 12389431 = 0 倒是可以理解, 但是BigDecimal不是高精度的计算么,讲道理不应该不会出现这种整除的问题吧
我们知道在BigDecimal做触发时,可以指定保留小数的参数,如果加上这个,是否会不一样呢?
BigDecimal origin = new BigDecimal(541253); BigDecimal now = new BigDecimal(12389431); BigDecimal val = origin.divide(now, 5, RoundingMode.HALF_UP); System.out.println(val);
输出结果为:
0.04369
所以说在指定了保留小数之后,则没有问题,所以大胆的猜测一下,是不是上面的几种case中,由于scale值没有指定时,默认值不一样,从而导致最终结果的精度不同呢?
简单的深入源码分析一下,执行的方式为 origin.divide(now, RoundingMode.HALF_UP);, 所以这个scale参数就瞄准origin对象,而这个对象,就只能去分析它的构造了,因为没有其他的地方使用
II. 源码定位 1. 整形传参构造分析下面这一行, 直接进入源码
BigDecimal origin = new BigDecimal(541253);
很明显的int传参构造,进去简单看一下
// java.math.BigDecimal#BigDecimal(int) public BigDecimal(int val) { this.intCompact = val; this.scale = 0; this.intVal = null; } public BigDecimal(long val) { this.intCompact = val; this.intVal = (val == INFLATED) ? INFLATED_BIGINT : null; this.scale = 0; }
so,很明确的知道默认的scale为0,也就是说当origin为正数时,以它进行的除法,不现实指定scale参数时,最终返回的都是没有小数的,同样看一眼,还有long的传参方式, BigInteger也一样
2. 浮点传参接下来就是浮点的scale默认值确认了,这个构造相比前面的复杂一点,源码就不贴了,太长,也看不太懂做了些啥,直接用猥琐一点的方式,进入debug模式,单步执行
@Test public void testBigDecimal() { BigDecimal origin = new BigDecimal(541253.0); BigDecimal now = new BigDecimal(12389431.1); BigDecimal tmp = new BigDecimal(0.0); }
根据debug的结果,第一个,scale为0; 第二个scale为29, 第三个scale为0
3. String传参依然是一大串的逻辑,同样采用单步debug的方式试下
@Test public void testBigDecimal() { BigDecimal origin = new BigDecimal("541253.0"); BigDecimal now = new BigDecimal("12389431.1"); BigDecimal t = new BigDecimal("0.0"); }
上面三个的scale都是1
4. 小结对于BigDecimal进行除法运算时,最好指定其scale参数,不然可能会有坑
对于BigDecimla的scale初始化的原理,有待深入看下BigDecimal是怎么实现的
最后贴一张乘法的图作为收尾
II. 其他 1. 一灰灰Blog: https://liuyueyi.github.io/he...一灰灰的个人博客,记录所有学习和工作中的博文,欢迎大家前去逛逛
2. 声明尽信书则不如,已上内容,纯属一家之言,因个人能力有限,难免有疏漏和错误之处,如发现bug或者有更好的建议,欢迎批评指正,不吝感激
微博地址: 小灰灰Blog
QQ: 一灰灰/3302797840
3. 扫描关注文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/71492.html
摘要:原因至于问题产生的原因,或者关于问题的更详细的描述,大家请看下面几个文章浮点运算浮点值运算舍入误差基础浮点数四则运算精度丢失问题解决方案这里主要讨论一下解决方案的问题,上面几篇文章的解决思路,都是重写加法减法乘法和除法运算。 问题背景 在 chrome 浏览器中调出开发者工具,在控制台窗口输入下面的表达式: 0.1 + 0.2 // 期望:0.3,结果:0.300...
摘要:使用,保证精度的同时,能精准的进行四舍六入计算。类精确的数学运算使用来实现精准度因为精度的原因构造方法的结果有一定的不可预知性,例如因此建议使用。算法规则四舍六入五考虑,五后非零就进一,五后皆零看奇偶,五前为偶应舍去,五前为奇要进一。 四舍六入计算 算法规则: 四舍六入五考虑, 五后非零就进一, 五后皆零看奇偶, 五前为偶应舍去, 五前为奇要进一。 使用BigDecimal,保证精度的...
摘要:前言在数据敏感的业务场景中,常常会碰到数据精度问题,尤其在金额显示占比统计等地方,该问题尤为显著。计算机原理真香数值的精度问题,其实是非常基础的计算机原理知识。前言 在数据敏感的业务场景中,常常会碰到数据精度问题,尤其在金额显示、占比统计等地方,该问题尤为显著。由于数据的每一位有效数字都包含真实的业务语义,一点点偏差甚至可能影响业务决策,这让问题的严重性上升了几个阶梯。 那,什么是精度丢失...
摘要:局部变量声明在函数内部的变量。在作用域范围内不能出现命名冲突。 java编程规范: 1.良好的标识符的命名 保留字不能作为标识符命名: class、public、static..., goto,const 区分大小写:helloWorld、HelloWorld 2.良好的注释习惯 3.良好的缩进:没遇到一个代码块缩进一次(一个tab键) 变量:代...
阅读 3241·2021-09-08 09:45
阅读 1222·2019-08-30 15:53
阅读 1482·2019-08-30 14:12
阅读 907·2019-08-29 17:01
阅读 2542·2019-08-29 15:35
阅读 372·2019-08-29 13:09
阅读 1915·2019-08-29 12:32
阅读 3070·2019-08-26 18:37