On the precision loss _javascript skill of JavaScript small number and large integer

Let's look at two questions:

0.1 + 0.2 = 0.3; False
9999999999999999 = 10000000000000000; True

The first problem is the problem of decimal precision, which has been discussed in many blogs in the industry. The second problem is that last year, the company had a system of databases in the data revisions, found that some of the strange phenomenon of duplication of data. This article will start from the specification, to the above question to make a summary.

Maximum integer

The numbers in JavaScript are stored with IEEE 754 double-precision 64-bit floating-point numbers, in the form of:

S x m x 2^e

S is a sign bit that indicates positive or negative. M is the mantissa, with bits. E is an exponent and has one bits. The range of e given in the ECMASCRIPT specification is [-1074, 971]. In this way, it is easy to derive the largest integer that JavaScript can represent:

1 x (2^53-1) x 2^971 = 1.7976931348623157e+308

The value is Number.MAX_VALUE.

Similarly, the value of Number.min_value can be deduced as follows:

1 x 1 x 2^ ( -1074) = 5e-324

Note that Min_value represents the nearest 0 positive number, not the smallest. The smallest number is-number.max_value.

Decimal precision is missing

The number of JavaScript is double-precision floating-point numbers, which are stored in binary in the computer. When the number of valid digits exceeds 52 digits, there is a loss of precision. Like what:

The decimal 0.1 binary is 0.0 0011 0011 0011 ... (Cycle 0011)
The decimal 0.2 binary is 0.0011 0011 0011 ... (Cycle 0011)
The addition of 0.1 + 0.2 can be expressed as:
e =-4; m = 1.10011001100...1100 (52-bit)
+ E =-3; m = 1.10011001100...1100 (52-bit)
---------------------------------------------
e =-3; m = 0.11001100110...0110
+ E =-3; m = 1.10011001100...1100
---------------------------------------------
e =-3; m = 10.01100110011...001
---------------------------------------------
= 0.01001100110011...001
= 0.30000000000000004 (decimal)

According to the above calculation, we can also draw a conclusion: when the decimal decimal binary representation of the limited number of no more than 52 bits, in JavaScript can be stored accurately. Like what:

0.05 + 0.005 = = 0.055/True

Further laws, such as:

0.05 + 0.2 = = 0.25/True
0.05 + 0.9 = = 0.95//False

It is necessary to consider the rounding modes of IEEE 754, which is interested in further study.

The precision of the large integer is lost

The question was seldom mentioned. First you have to figure out what the problem is:

1. What is the largest integer that JavaScript can store?

The question has been answered before, and is Number.MAX_VALUE, a very large number.

2. What is the largest integer that JavaScript can store without losing precision?

According to the S X m x 2^e, the sign bit is positive, the 52-bit mantissa is filled 1, the index e takes the maximum value of 971, obviously, the answer is still number.max_value.

What exactly is our problem? Back to the start code:

9999999999999999 = 10000000000000000; True

Obviously, 16 9 is still far less than 308 10. This problem has nothing to do with max_value, but it has to belong to the mantissa M only 52 digits up.

You can use code to describe:

var x = 1; To reduce the amount of computation, the initial value can be set to a larger point, such as Math.pow (2, 53)-10
while (x!= x + 1) x + +;
x = 9007199254740992 that 2^53

That is, when x is less than or equal to 2^53, you can ensure that X's precision is not lost. When x is greater than 2^53, the precision of X is likely to be lost. Like what:

X is 2^53 + 1 o'clock, the binary representation is:
10000000000...001 (a total of 52 in the middle 0)
When storing with double-precision floating-point numbers:
e = 1; m = 10000..00 (Total 52 0, where 1 is hidden bit)
Obviously, this is the same as 2^53 storage.

According to the above ideas can be introduced, for 2^53 + 2, the second system for 100000 ... 0010 (the Middle 51 0), also can be stored accurately.

Rule: When x is greater than 2^53 and the binary number of significant digits is greater than 53 digits, there is a loss of precision. This is essentially the same as the loss of decimal precision.

Hidden bit can refer to: A tutorial about Java double type.

Summary

The precision of decimal and large integers is lost, not only in JavaScript. Strictly speaking, any programming language (C/c++/c#/java, etc.) that uses IEEE 754 floating-point format to store floating-point types has a problem with loss of precision. In C #, Java, provides the Decimal, BigDecimal encapsulation class to handle the corresponding, only to avoid the loss of precision.

Note: There are already decimal proposal in the ECMAScript specification, but it is not yet formally adopted.

The final Test everyone:

Number.MAX_VALUE + 1 = numer.max_value;
Number.MAX_VALUE + 2 = numer.max_value;
...
Number.MAX_VALUE + x = = Numer.max_value;
Number.MAX_VALUE + x + 1 = Infinity;
...
Number.MAX_VALUE + Number.MAX_VALUE = = Infinity;
Problem:
1. What is the value of x?
2. Infinity-number.max_value = = x + 1; Is it true or false?

Above this article on the JavaScript small number and large integer precision loss is small to share all the content of everyone, hope to give you a reference, but also hope that we support the cloud habitat community.