JavaScript 中 0.1 + 0.2 的精度以及数字类型的整理

JavaScript 中数字是如何表示的

JavaScript 中的所有数字都是浮点数,使用 64 位二进制来表示,也叫做双精度浮点型,这种方式出自于 IEEE-754 标准。

64 位二进制的表达方式

计算公式

公式解读

  • S (Sign/1bit):符号部分,当 S=0,V 为正数;当 S=1,V 为负数。
  • E (Exponent/8bits):指数部分。E 是一个无符号整数,因为长度是11位,取值范围是 0~2047。但是科学计数法中的指数是可以为负数的,所以人们约定减去一个中间数 1023, [0,1022]  表示为负, [1024,2047]  表示为正
  • M (Mantissa/23bits):表示有效数字,大于等于1,小于2。第一位 1 可以被舍去,只保留小数部分节省一位有效数字。

指数 E 还分为三种情况:

  1. E 不全为 0 或不全为 1。这时,浮点数就采用上面的规则表示,即指数 E 的计算值减去 127(或 1023 ),得到真实值,再将有效数字 M 前加上第一位的 1。
  2. E 全为 0。这时,浮点数的指数 E 等于 1-127(或者 1-1023 ),有效数字 M 不再加上第一位的 1,而是还原为 0.xxxxxx 的小数。这样做是为了表示 ± 0,以及接近于 0 的很小的数字。
  3. E 全为 1。这时,如果有效数字 M 全为 0,表示 ± 无穷大(正负取决于符号位s);如果有效数字 M 不全为 0,表示这个数不是一个数(NaN)。

2^E 代表什么:

上面的公式其实是科学计数法的表示方式,十进制中我们如果想要对小数点进行前移或后移,就是 (一个数 :heavy_multiplication_x: 10^1) 表示小数点往后移一位,同样的在二进制中就是采用(一个二进制数 :heavy_multiplication_x: 2^1)表示二进制表达的数字的小数点往后移一位。

IEEE 754 中规定:

对于 32 位的浮点数,最高的 1 位是符号位 S,接着的 8 位是指数 E,剩下的 23 位为有效数字 M;

对于 64 位的浮点数,最高的 1 位是符号位 S,接着的11位是指数 E,剩下的 52 位为有效数字 M。

0.1 + 0.3 !== 0.3

> 0.1 + 0.2
0.30000000000000004

0.1 和 0.2 转换成 2 进制

> (0.1).toString(2)
"0.0001100110011001100110011001100110011001100110011001101"

> (0.2).toString(2)
"0.001100110011001100110011001100110011001100110011001101"

// 0.1 + 0.2
0.00011001100110011001100110011001100110011001100110011010 +
0.0011001100110011001100110011001100110011001100110011010 =
0.0100110011001100110011001100110011001100110011001100111

// 转成十进制正好是 0.30000000000000004

误差怎么来的?

由于 IEEE 754 的规定,用 64 位二进制来表示数字,如果我们手动去转换一下十进制的 0.1到二进制, 1100部分是会一直循环下去,显然如果你找一个位置阶段只取其中的一部分值的话,精度就不准确了,而 【M (Mantissa/23bits):表示有效数字】只有 52 位可以存储,看一下转换的过程

// 0.1 -> 二进制表示
0001100110011001100110011001100110011001100110011001100(1100一直循环下去)

// 按照 IEEE 754 的规定,套公式,用科学计数法表示成 1.xxx * 2^-x 的方式,所以小数点往后移
1.100110011001100110011001100110011001100110011001100(1100一直循环下去)

// 小数点后的这部分是尾数,尾数长度 == 小数值精度 == 尾数所代表二进制的个数越多就越精确,而按照规定我们只有 52 位,超出的能进位就进位,所以最终表示为
1.100 1100 1100 1100 1100 1100 1100 1100 1100 1100 1100 1100 11010

这么一来,像 0.1 这样的数值就不是精确的,不精确的两个数值做运算,结果显而易见,这里有个网站可以将二进制的展示方式表现出来。

0.1 digits visualization

另外根据二进制转换为十进制的公式,如果你使用 Math.pow() 去计算的话,会发现结果就是 0.1 ,然而我经过手算( 0.1.toString(2) 转换为十进制)后实际结果是和 0.1.toPrecision(x)相近的,因为我是按照实际保留的尾数进行计算的,精度上没有 0.1.toPrecision(x) 高,但是在相同精度内结果是一致。

> Math.pow(2,-4) + 
Math.pow(2,-5) + 
Math.pow(2,-8) + 
Math.pow(2,-9) + 
Math.pow(2,-12) + 
Math.pow(2,-13) +
Math.pow(2,-16) + 
Math.pow(2,-17) + 
Math.pow(2,-20) + 
Math.pow(2,-21) + 
Math.pow(2,-24) + 
Math.pow(2,-25) +
Math.pow(2,-28) + 
Math.pow(2,-29) + 
Math.pow(2,-32) + 
Math.pow(2,-33) + 
Math.pow(2,-36) + 
Math.pow(2,-37) +
Math.pow(2,-40) +
Math.pow(2,-41) +
Math.pow(2,-44) +
Math.pow(2,-45) +
Math.pow(2,-48) +
Math.pow(2,-49) +
Math.pow(2,-52) +
Math.pow(2,-53) +
Math.pow(2,-55)
0.1

0.1.toPrecision(29)
"0.10000000000000000555111512313"

可以+web前端扣扣裙:939106847 免费网课在线学习以及问题解答、项目指导服务,配合强大的学习工具,带你完成九大实战项目,经历从零基础到专业前端工程师的完美蜕变。


欢迎初学和进阶中的小伙伴。裙里有免费的学习资料,还有专业老师为你解惑,更有免费体验课、免费直播课等福利不定期放送。

<think>嗯,用户问的是为什么在Python中执行print(0.1+0.2)会得到0.30000000000000004,而0.1+0.2 == 0.3的结果是False。这个问题看起来是关于浮点数精度的问题,我之前也学过一些相关的知识,不过得仔细理清楚思路。 首先,我需要回忆一下浮点数在计算机中的表示方式。根据IEEE 754标准,浮点数是二进制表示的,所以像0.1这样的十进制小数转换成二进制时可能会出现无限循环的情况。比如0.1在二进制中是0.0001100110011...循环,无法精确表示,只能存储一个近似值。 那0.10.2在转换成二进制浮点数的时候都会被近似处理,这样它们的和自然可能会有误差。当计算0.1 + 0.2时,实际上是在两个近似值相加,结果可能稍微大一点或者小一点,所以结果可能不是精确的0.3,而是接近0.3的一个数,比如0.30000000000000004。 接下来,用户用print输出的时候,为什么显示的是0.30000000000000004呢?这可能和Python的浮点数显示机制有关。Python在打印浮点数时会显示足够多的位数以区分不同的浮点数值,所以即使结果非常接近0.3,它也会显示出这些微小的差异。 然后是第二部分,为什么0.1+0.2 == 0.3的结果是False。这是因为左边的计算结果是一个近似值,而右边的0.3同样在转换成浮点数时也会有近似误差。两者的近似误差可能不同,导致它们不严格相等。 不过这里可能需要更深入一点的分析。比如,0.3在二进制中的表示是否也是无法精确表示的?是的,0.3在二进制中也是无限循环小数,所以存储的时候也是近似值。但为什么这两个近似值相加后的结果和另一个近似值不相等呢?这是因为误差的积累方向可能不同。例如,0.10.2各自的近似值可能都被略微放大,导致它们的和比0.3的近似值更大,从而不相等。 这时候需要举例子,假设0.1被存储为A,0.2被存储为B,而0.3被存储为C。A和B的和可能比C大一点或者小一点,具体取决于它们的近似方式。当使用双精度浮点数时,0.1+0.2的实际结果可能比0.3的浮点数表示大一点点,所以比较时就会得到False。 再思考一下,是否所有编程语言都会有这样的问题?比如在JavaScript中,0.1 + 0.2也会得到类似的结果,而比较结果也是False。这说明这是浮点数表示法的通病,而不仅仅是Python的问题。不过不同的语言可能在输出时处理方式不同,有的可能会四舍五入显示,比如只显示到小数点后几位,而Python默认显示更多位数,所以会看到这个差异。 用户可能之前遇到过类似的问题,比如在比较浮点数时出现预期外的结果,所以需要解释清楚原因,并提供解决方法。例如,建议不要直接比较浮点数是否相等,而是检查它们的差值是否在一个很小的误差范围内。 另外,用户可能没有意识到浮点数的这种特性,尤其是在处理金融计算时,使用浮点数可能导致错误,这时候应该建议使用decimal模块或者定点数来处理精确的小数运算。 总结来说,这个问题的核心是浮点数的二进制表示导致的精度问题,加上运算过程中的误差积累,导致看似简单的算术在计算机中并不精确。需要从IEEE 754标准、二进制转换误差、运算中的误差传播以及比较时的注意事项这几个方面来解答。</think>这两行代码的结果源于**浮点数在计算机中的二进制表示误差**,具体原因与 IEEE 754 标准的实现相关。以下是详细解释: --- ### **1. 浮点数的二进制表示误差** - **十进制转二进制的无限循环问题** - 0.10.2 在十进制中是有限小数,但在二进制中是无限循环小数: - `0.1`(十进制)→ `0.0001100110011001100110011...`(二进制) - `0.2`(十进制)→ `0.001100110011001100110011...`(二进制) - 计算机使用有限的二进制位(如 64 位双精度浮点数)存储这些值,必须进行**截断**,导致精度丢失。 - **0.1 + 0.2 的实际计算过程** - 截断后的二进制值相加时,误差会被放大。 - 例如,假设 `0.1` 和 `0.2` 的近似值分别为 `A` 和 `B`,则 `A + B` 的实际结果可能略大于 `0.3` 的近似值。 --- ### **2. 结果为何是 `0.30000000000000004`** - **IEEE 754 双精度浮点数的精度限制** 双精度浮点数(64 位)的精度约为 15-17 位有效数字。计算 `0.1 + 0.2` 时,误差的积累会导致结果的实际存储值为: ``` 0.300000000000000044408920985006... ``` 但 Python 在输出时会显示足够多的位数以体现这一误差,最终输出 `0.30000000000000004`。 - **打印行为的特殊性** 某些编程语言(如 Python)默认显示更多小数位以暴露精度问题,而其他语言(如 JavaScript)可能隐藏部分位数(例如输出 `0.30000000000000004` 还是 `0.3` 取决于语言设计)。 --- ### **3. 为什么 `0.1 + 0.2 == 0.3` 返回 `False`** - **浮点数的“假相等”与真实误差** - `0.3` 本身也无法被精确表示为二进制浮点数,它的实际存储值为: ``` 0.299999999999999988897769753748... ``` - 当 `0.1 + 0.2` 的结果(`0.30000000000000004`)与 `0.3` 的近似值比较时,两者的二进制表示存在微小差异,因此结果为 `False`。 --- ### **4. 浮点数运算的通用问题** - **所有编程语言都存在此问题** 这是由浮点数的底层硬件实现决定的,与语言无关。例如: - **Java**: `System.out.println(0.1 + 0.2 == 0.3);` → `false` - **误差的不可预测性** 误差大小取决于数值的二进制表示特性,例如: - `0.5 + 0.5` 可以精确表示,因此 `0.5 + 0.5 == 1.0` → `True` - `0.125 + 0.125` 也能精确表示(因为 `0.125 = 1/8 = 2^-3`)。 --- ### **如何避免此类问题?** 1. **容忍微小误差的比较** 使用误差范围(epsilon)代替直接相等性判断: ```python def is_close(a, b, epsilon=1e-9): return abs(a - b) < epsilon print(is_close(0.1 + 0.2, 0.3)) # True ``` 2. **使用高精度计算库** Python 的 `decimal` 模块可精确表示十进制小数: ```python from decimal import Decimal print(Decimal('0.1') + Decimal('0.2') == Decimal('0.3')) # True ``` 3. **避免浮点数用于精确场景** 金融计算等场景应使用整数(以分为单位)或定点数库。 --- ### **总结** 浮点数的二进制表示特性导致 `0.1 + 0.2` 无法精确等于 `0.3`。这是计算机科学中的经典问题,理解其原理后,可通过误差容忍或高精度库规避问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值