JavaScript의 Number 유형에 대한 일반적인 오해 뒤에 있는 원칙과 해결책

이 글은 JavaScript에 대한 관련 지식을 소개합니다. 숫자 유형에 대한 일반적인 오해의 원리와 해결 방법을 포함하여 숫자 유형에 대한 관련 지식을 주로 소개합니다.

[관련 권장사항: JavaScript 비디오 튜토리얼, web front-end]

JavaScript에는 내부적으로 배정밀도 부동 소수점으로 표현되는 숫자 유형의 값 유형이 하나만 있습니다. point 형은 다른 언어에서는 double 형이므로 실제로 JavaScript에는 정수 형이 없습니다. 값은 부동 소수점 숫자로 처리되며 저장 방법은 IEEE 754 국제 표준을 따릅니다. 따라서 자바스크립트에서는 3과 3.0이 같은 값으로 처리됩니다.

3.0 === 3 // true

정수의 경우 정확하게 계산할 수 있는 정수의 범위는 −253-2^{53}−253 ~ 2532^{53}253입니다. , 두 끝점을 포함하지 않고 이 범위 내에 있으면 정수를 안전하게 사용할 수 있습니다. 10진수 외에도 정수는 8진수 또는 16진수 리터럴로 표시될 수 있습니다. 8진수 리터럴의 첫 번째 숫자는 0이어야 하며, 리터럴의 값이 범위를 벗어나는 경우 일련의 8진수 숫자가 와야 합니다. , 선행 0은 무시되고 다음 값은 10진수로 구문 분석됩니다. 엄격 모드에서 8진수를 표현하면 ES6에서는 8진수에 접두사 0o를 사용해야 함을 추가로 명시합니다. 예:

(function(){
  console.log(0o11 === 011)
})()
// true
// 严格模式
(function(){
  'use strict';
  console.log(0o11 === 011)
})()
// Uncaught GyntaxError

16진수 리터럴 값의 처음 두 자리는 0x여야 하며 그 뒤에는 16진수 숫자(0 ~ 9 및 A ~ F)가 와야 합니다. 여기서 A ~ F는 대문자 또는 소문자일 수 있습니다. ES6에서는 접두사 0b(또는 0B)를 사용하여 이진 쓰기 방법을 확장했습니다.

앞서 JavaScript 런타임의 Number 유형에 대해 간략하게 소개한 후 공식적으로 이러한 일반적인 문제를 소개하기 시작했지만 먼저 Number 유형의 데이터 저장 방법을 이해해야 합니다.

1.

Number in JavaScript 이 유형은 다른 언어의 double 유형인 배정밀도 부동 소수점을 사용합니다. 배정밀도 부동 소수점 숫자는 저장을 위해 8바이트, 즉 64비트를 사용합니다. 국제 표준 IEEE 754에 따라 저장 프로시저

• 부동 소수점 숫자를 해당 이진수로 변환하고 과학적 표기법을 사용하여

• 변환된 숫자를 다음과 같은 값으로 표현합니다. 실제로 IEEE 754 표준을 통해 컴퓨터에 저장됩니다.

IEEE 754 표준에 따르면 모든 이진 부동 소수점 숫자 V는 다음과 같이 표현될 수 있습니다.

예를 들어 10진수 5.0은 이진수 101.0으로 기록되며 이는 1.01*221.01과 같습니다. * 2^21.01* 22, 여기서 S=0, M=1.01, E=2입니다.

IEEE 754에서는 아래 그림과 같이 32비트 부동 소수점 숫자의 경우 가장 높은 1비트는 부호 비트 S, 다음 8비트는 지수 E, 나머지 23비트는 유효 숫자 M이라고 규정합니다. :

64비트의 경우 그림과 같이 부동 소수점 수의 최상위 1비트는 부호 비트 S, 다음 11비트는 지수 E, 나머지 52비트는 유효 숫자 M입니다. 아래:

참고: IEEE754 유효 숫자 M 및 지수 E에는 몇 가지 특별한 규정도 있습니다.

앞서 언급했듯이 1 지수 E의 경우 상황이 더 복잡합니다. 먼저, E는 부호 없는 지수(unsigned exComponent)로, E가 8비트일 경우 그 값 범위는 0~255, E가 11비트일 경우 그 값 범위는 0~2047임을 의미한다. 그러나 과학적 표기법의 E는 음수 값을 가질 수 있으므로 IEEE 754에서는 E의 실제 값을 중간 숫자에서 빼야 한다고 규정합니다. 8자리 E의 경우 이 중간 숫자는 127이고 11자리 E의 경우입니다. E , 중간 숫자는 1023입니다.

예를 들어 2102^{10}210의 E는 10이므로 32비트 부동 소수점 숫자로 저장할 때는 10+127=137, 즉 10001001로 저장해야 합니다.

그러면 인덱스 E는 세 가지 상황으로 나눌 수 있습니다:

• E不全为0或不全为1：这时，浮点数就采用上面的规则表示，即指数E的计算值减去127（或1023），得到真实值，再将有效数字M前加上第一位的1。

• E全为0：这时，浮点数的指数E等于1 ~ 127（或1 ~ 1023），有效数字M不再加上第一位的1，而是还原成0.xxxxxxx的小数，这样做是为了表示±0，以及接近0的很小的数字。

• E全为1：这时，如果有效数字M全为0，表示±无穷大（正负取决于符号位S）；如果有效数字M不全为0，表示这个数不是一个数（NaN）。

示例：浮点数 9.0 如何用二进制表示？还原成十进制又是多少？

首先，浮点数 9.0 等于二进制的 1001.0，即 1.001∗231.001 *2^31.001∗23

那么，第一位的符号位 S=0，有效数字 M 等于 001 后面再加 20 个 0，凑满 23 位，指数 E 等于 3+127=130，即 10000010。

所以，写成二进制形式，应该是 S+E+M，即0 10000010 001 0000 0000 0000 0000 0000。这个 32 位的二进制数，还原成十进制，正是 1091567616。

注：虽然在 JavaScript 中无论是小数还是整数都是按照64位的浮点数形式存储，但是进行整数运算会自动转换为32位的有符号整数，例如位运算，有符号整数使用31位表示整数的数值，用第32位表示整数的符号，数值范围是−231-2^{31}−231 ~ 2312^{31}231。

二、浮点数运算的精度丢失

问题缘由

众所周知在 JavaScript 中 0.1+0.2 不等于 0.3，实际上所有浮点数值存储遵循 IEEE 754 标准的编程语言中都会存在这个问题，这是因为计算机中小数的存储先是转换成二进制进行存储的，而 0.1、0.2 转换成二进制分别为：

(0.1)10 => (00011001100110011001(1001)...)2 (0.2)10 => (00110011001100110011(0011)...)2

可以发现，0.1 和 0.2 转成二进制之后都是一个无限循环的数，前面提到尾数位只能存储最多 53 位有效数字，这时候就必须来进行四舍五入了，而这个取舍的规则就是在 IEEE 754 中定义的，0.1 最终能被存储的有效数字是

0001(1001)(1001)(1001)(1001)(1001)(1001)(1001)(1001)(1001)(1001)(1001)(1001)101 + (0011)(0011)(0011)(0011)(0011)(0011)(0011)(0011)(0011)(0011)(0011)(0011)(0011)01 = 0100(1100)(1100)(1100)(1100)(1100)(1100)(1100)(1100)(1100)(1100)(1100)(1100)111

最终的这个二进制数转换成十进制的就是 0.30000000000000004 ，这儿需要注意，53 位的存储位指的是能存 53 位有效数字，因此前置的 0 不算，要往后再取到  53 位有效数字为止。

因此，精度丢失的问题实际上用一句话概括就是计算机中用二进制存储小数，而大部分小数转成二进制后都是无限循环的值，因此存在取舍问题，也就是精度丢失。

解决办法

ES6 在 Number 对象上新增了一个极小常量：Number.EPSILON，值为 2.220446049250313e-16，引入这么一个常量就是为了为浮点数计算设置一个误差范围，如果这个误差小于 Number.EPSILON 我们就认为得到了准确结果。

三、大整数的运算精度丢失及溢出

问题缘由

在介绍问题的具体缘由之前我想先给大家介绍一下所谓最大安全整数范围以及最大数字绝对值的范围是如何得到的？

JavaScript 能够表示的数字的绝对值范围是 5e-324 ~ 1.7976931348623157e+308，这两个取值可以通过 Number.MIN_VALUE 和 Number.MAX_VALUE 这两个字段来表示，如果某次计算的结果得到了一个超出 JavaScript 数值范围的，那么这个数值会自动被转换为特殊的 Infinity 值，具体来说，如果这个数是负数，则会被转换成 -Infinity（负无穷），如果这个数值是正数，则会被转换成 Infinity（正无穷）。

示例：

console.log(Number.MAX_VALUE) // 1.7976931348623157e+308
console.log(Number.MIN_VALUE) // 5e-324
console.log(Number.MAX_VALUE + Number.MAX_VALUE) // Infinity

那么这个取值范围是如何得到的呢？

前面说到 JavaScript 中数值的保存采用的是双精度浮点型，遵循 IEEE 754 标准，在 ECMAScript 规范中规定指数 E 的范围在 -1074 ~ 971，双精度浮点型中有效数字 M 的存储位为52，但是有效数字 M 由于可以省略第一位1，节省一个存储位，因此有效数字M可以存储的范围为 1 ~ 2532^{53}253，因此 JavaScript 中 Number 能表示的最大数字绝对值范围是 2−10742^{-1074}2−1074 ~ 253+9712^{53+971}253+971。

注：通过 Number.isFinite()（ES6引入）和 isFinite() 方法可以判断一个数值是不是有穷的，即如果参数位于最小与最大数值之间时会返回 true。

让我们回归主题，为什么会出现大整数的运算精度丢失及溢出呢？

JavaScript 中最大安全整数的范围是 −253-2^{53}−253 ~ 2532^{53}253，不包括两个端点，即 -9007199254740991 ~ 9007199254740991，可以通过 Number.MIN_SAFE_INTEGER 和 Number.MAX_SAFE_INTEGER 字段查询，超出这个范围的整数计算都是不准确的，例如：

console.log(Number.MAX_SAFE_INTEGER) // 9007199254740991
console.log(Number.MIN_SAFE_INTEGER) // -9007199254740991
console.log(9007199254740991 + 2) // 9007199254740992

最大安全整数9007199254740991对应的二进制数如图：

53位有效数字都存储满了之后，想要表示更大的数字，就只能往指数数加一位，这时候尾数因为没有多余的存储空间，因此只能补0。

如图所示，在指数位为53的情况下，最后一位尾数位为0的数字可以被精确表示，而最后一位尾数位为1的数字都不能被精确表示。也就是可以被精确表示和不能被精确表示的比例是1:1。

同理，当指数为54的时候，只有最后两位尾数为00的可以被精确表示，也就是可以被精确表示和不能被精确表示的比例是1:3，当有效位数达到 x(x>53) 的时候，可以被精确表示和不能被精确表示的比例将是1 : 2^(x-53)^ - 1。

可以预见的是，在指数越来越高的时候，这个指数会成指数增长，因此在 Number.MAX_SAFE_INTEGER ~ Number.MAX_VALUE 之间可以被精确表示的整数可以说是凤毛麟角。

之所以会有最大安全整数这个概念，本质上还是因为数字类型在计算机中的存储结构。在尾数位不够补零之后，只要是多余的尾数为1所对应的整数都不能被精确表示。

可以发现，不管是浮点数计算的计算结果错误和大整数的计算结果错误，最终都可以归结到JS的精度只有53位（尾数只能存储53位的有效数字）。

解决办法

那么我们在日常工作中碰到这两个问题该如何解决呢？

大而全的解决方案就是使用 mathjs，看一下 mathjs 的输出：

math.config({
    number: 'BigNumber',      
    precision: 64 
});
console.log(math.format(math.eval('0.1 + 0.2'))); // '0.3'
console.log(math.format(math.eval('0.23 * 0.34 * 0.92'))); // '0.071944'
console.log(math.format(math.eval('9007199254740991 + 2'))); 
// '9.007199254740993e+15'

【相关推荐：JavaScript视频教程、web前端】

위 내용은 JavaScript의 Number 유형에 대한 일반적인 오해 뒤에 있는 원칙과 해결책의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!