Precision loss of small numbers and big integers in Javascript

Original article: http://demon.tw/copy-paste/javascript-precision.html

Precision loss of small numbers and big integers in Javascript

Title: Precision loss of small numbers and big integers in Javascript
Author: demon
Link: http://demon.tw/copy-paste/javascript-precision.html
Copyright: all articles in this blog comply with the terms of the "signature-non-commercial use-share 2.5 mainland China" agreement.

Let's take a look at two questions:

0.1 + 0.2 == 0.3; // false9999999999999999 == 10000000000000000; // true

The first problem is the decimal precision, which has been discussed in many blogs in the industry. The second problem is that last year, when the company made a system database for data subscription, it found that some data was duplicated. This article will summarize the above issues based on the specifications.

Maximum integer

The numbers in JavaScript are stored with IEEE 754 dual-precision 64-bit floating point numbers in the format:

s x m x 2^e

S is the sign bit, indicating positive and negative. M is the ending number, with 52 bits. E is an index with 11 bits. in the ecmascript specification, the range of E is [-1074,971]. in this way, it is easy to export the largest integer that javascript can represent:

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

This value is exactly number. max_value

Similarly, the value of number. min_value can be exported as follows:

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

Note that min_value indicates the positive number closest to 0, rather than the smallest number. The smallest number is-number. max_value.

Decimal precision loss

The binary value of decimal 0.1 is 0.0 0011 0011... (Loop 0011) the binary value of decimal 0.2 is 0.0011 0011... (Loop 0011) 0.1 + 0.2 addition can be expressed as: E =-4; M = 1. 10011001100... 1100 (52 bits) + E =-3; M = 1. 10011001100... 1100 (52 bits) --------------------------------------------- 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 number represents a finite number of no more than 52 digits, it can be precisely stored in JavaScript. For example:

0.05 + 0.005 == 0.055 // true

Further rules, such:

0.05 + 0.2 == 0.25 // true0.05 + 0.9 == 0.95 // false

The rounding modes of IEEE 754 needs to be considered. If you are interested, you can further study it.

Precision loss of large Integers

This issue is rarely mentioned. First, you have to find out what the problem is:

1. What is the maximum integer that javascript can store?

The answer to this question is number. max_value, a very large number.

2. What is the maximum integer that javascript can store without losing precision?

Accordings x m x 2^e, The symbol bit is positive, the 52-bit ending number is fully filled with 1, and the index e gets the maximum value of 971. Obviously, the answer is still number. max_value.

What is our problem? Return to the starting code:

9999999999999999 == 10000000000000000; // true

Obviously, 16 9 is far smaller than 308 10. This problem has nothing to do with max_value and has to be attributed to the ending number M with only 52 bits.

You can use code to describe:

VaR x = 1; // to reduce the computational workload, you can set a larger initial value, such as math. Pow (2, 53)-10 while (X! = X + 1) x ++; // X = 9007199254740992 that is, 2 ^ 53

That is to say, when X is less than or equal to 2 ^ 53, the accuracy of X will not be lost. When X is greater than 2 ^ 53, the precision of X may be lost. For example:

When X is 2 ^ 53 + 1, its binary representation is: 10000000000... 001 (a total of 52 0 in the middle) with Double Precision Floating Point storage: E = 1; M = 10000 .. 00 (52 zeros in total, where 1 is hidden bit) Obviously, this is the same as the storage of 2 ^ 53.

According to the above ideas, we can launch the binary 100000 for 2 ^ 53 + 2... 0010 (51 in the middle), can be precisely stored.

Rule: when X is greater than 2 ^ 53 and the binary valid digits are greater than 53 bits, there will be loss of precision. This is essentially the same as the loss of decimal precision.

For more information about hidden bit, see a tutorial about Java double type.

Summary

The precision of decimal places and big integers is lost, not only in JavaScript. Strictly speaking, any programming language (C/C ++/C #/Java) that uses the IEEE 754 floating point format to store the floating point type has the precision loss problem. In C # and Java, the decimal and bigdecimal encapsulation classes are provided for corresponding processing to avoid precision loss.

Note: The ecmascript specification already contains decimal proposal, but has not yet been formally accepted.

Finally, you can take the exam:

Number. max_value + 1 = number. max_value; number. max_value + 2 = number. max_value ;... number. max_value + x = number. 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?

References

• Wikipedia: Float Point
• Es5: The number type
• Javascript-max_int: Number limits
• Maxinum number
• About the loss of JavaScript computing accuracy

Original article:Precision loss of small numbers and big integers in Javascript