惊闻 0.1 + 0.2 !== 0.3,赶忙计算得验证,发现,0.1 加 0.2 等于 0.30000000000000004
0.1 + 0.2 == 0.30000000000000004 返回 True
谁能给我解释下为什么,javascript这是要闹哪样啊。。。
惊闻 0.1 + 0.2 !== 0.3,赶忙计算得验证,发现,0.1 加 0.2 等于 0.30000000000000004
0.1 + 0.2 == 0.30000000000000004 返回 True
谁能给我解释下为什么,javascript这是要闹哪样啊。。。
因为计算机是二进制来表示浮点数的,无法准确表示一个浮点数,只能逼近。所以0.1+0.2并不是精确的等于0.3,不仅禁是javascript这样,这不是语言的问题。
你要判断两个浮点数是否相等,还是建议用逼近的比较,比如
if(fabs(a-b) < 1E-10) ;//we think a is equals to b.
浮点数都是这样的, 因为你的0.1是会变成二进制的
原理可以参考
http://www.pythonpub.com/python-2-7-t...
虽然是python的文档, 但是各个语言的浮点数大概都是这个意思
8 回答4.8k 阅读✓ 已解决
6 回答3.5k 阅读✓ 已解决
5 回答2.9k 阅读✓ 已解决
5 回答6.4k 阅读✓ 已解决
4 回答2.3k 阅读✓ 已解决
4 回答2.8k 阅读✓ 已解决
3 回答2.5k 阅读✓ 已解决
注:下面为早期学习记录未注明原作者,找到时补上。
JavaScript的number类型按照ECMA的JavaScript标准,它的Number类型就是IEEE 754的双精度数值,相当于java的double类型。IEEE 754标准《二进制浮点数算法》(www.ieee.org)就是一个对实数进行计算机编码的标准。因此精度问题不止JS这门语言独有。
无论是用纸张记录数值,还是用计算机记录数值,都必须用某种编码方案来表达数值。必须理解的是,用编码表达的数值不是数值本身,而只是数值的一种人类或计算机可理解的描述。任何编码方案都有其局限,要么是表达范围(精度)方面的限制,要么是其他复杂性方面的制约。
绝对完美的数值编码方案是不存在的,为了处理方便,这个标准引入了大量的折衷和妥协,建立在这种表达方式上的算法(例如除法运算)也一样。由于数值表达方式存在“缺陷”,运算结果不可避免地堆聚起越来越多的误差。
按IEEE 754格式保存的浮点数精度相当于带有15、16或17位小数位数的十进制小数,由于存在二进制和十进制的转换问题,具体的位数会发生变化。要获得最高的转换精度,必须指定17位的小数——此时可以相信前15位的精度。
在JavaScript中输出下面这些数值(注意不能作为字符串输出):0.1000000000000000000000000001(28位小数)、0.100000000000000000000000001(27位小数)、0.1000000000000000000000000456(28位小数)、0.09999999999999999999999(23位小数),显示出来的结果都是数值0.1。又如,如果输出1/3的有理数表达式,结果是0.3333333333333333。
因此JavaScript小数在做四则运算时,精度会丢失。
原则当然也有一些方法可以来保证一定的精度:http://jiangzhengjun.iteye.com/blog/4...
也有人总结了一些原则:
■ 大多数Web页面不需要小数
避免使用小数,尽量设法使用整数。确保数组的索引都是整数。按分(而不是元)计算金额。百分比放大100倍计算以避免出现小数。尽可能不用除法(/)和模(%)运算,因为大多数情况下它们直接导致出现浮点数。如果必须使用除法,立即用Math.round方法回归整数运算。
■ 如果必须使用浮点数,则尽可能引入冗余小数位——即在程序要求的运算精度之外,再增加小数位
如果程序需要5位数字的小数精度,则在运算中至少保留6位的小数,8位更好。冗余位越多,累计误差的影响越小。
■ 避免在同一个表达式中使用相差太大或太小的数值
对两个非常接近的数值执行减法或比较操作很容易出错。将很小的数值和很大数值相加无异于浪费时间,小的数值很可能被当作0。不过,很小的数值乘以很大的数值一般不会出现问题,例如2 * 12345678会得到正确的结果24691356。但是,0.1 - 0.09的结果是0.010000000000000009。
■ 用isFinite()和isNaN()检查运算结果
通过表单提交任何数值运算结果之前,一定要先检查数据的合法性。
■ 慎用数值运算
程序涉及的数值运算越少,引入误差的可能就越小。视浮点数为贵客,不可任意驱使。