First, Javascript precision issues business background

The JS problem of 0.1+0.2 = 0.3000000000000004 is a headache in many business scenarios. Especially in the large e-commerce enterprises, money fund stock industry web page, JS four calculation and toFixed accuracy is impossible to prevent. Jd.com has a online toFixed accuracy problem, almost a mistake:

Second, analyze the causes of Javascript accuracy problems

1, super large number and floating point number four operation accuracy problems

Before analyzing the JS precision problem, it is necessary to briefly describe the JS calculation method background

1. All calculations inside JS are done in binary mode.

The length of binary values cannot be stored in JS without limit. (Up to 52 digits)

Both of these are not hard to understand. Computers are all zeros and ones at the bottom, of course, and computers can’t keep anything infinitely long.

Knowing these two points, it is not difficult to understand why JS will have problems when calculating super large numbers, just like you can never calculate how many stars there are in the universe, nor can computers.

The answer is that inside JS, floating-point numbers are also represented by very long binary numbers (see computer principles for details).

In the JS world, 0.1 to binary is 0.00011001100110011… You will find that the string of numbers is an infinite number of 0.11s in the loop.. (0.0 (0011) (0011) (0011) (0011)… There is no way, in JS, floating point number is converted to infinite binary, so JS can only intercept the first 52 bits of the binary string for binary addition, so the following need not say again, naturally will appear precision problems.

This also explains why adding or subtracting integers in JS does not cause problems, but superlarge and floating point calculations do.

2, toFixed() precision problem

The toFixed problem is simply a browser pit.

As you can see, under IE and Chrome, a simple rounding gives a completely different result. It’s because different browser vendors don’t have uniform standards for rounding that we developers are stuck in. In IE, toFixed is the conventional rounding methods, goose, in chrome is adopting finance more precise four and six into fifty percent both sides method, although this method is more scientific, more accurate, but, after all, most people not financial experts are not scientists or rounded more easily accepted by ordinary people…

Correction:

In the toFixed accuracy of the direct reference to most of the network interpretation, lack of practice, no in-depth study, the above round six into five double method has been repeatedly verified is actually wrong (the figure above hit the face. After reviewing some information again, toFixed native API is verified by the official:

This method was found to be consistent with the results after more than 10 toFixed verification, and should be the correct source of the problem.

(PS: This error has no impact on the solution)

Third, the ultimate solution to the precision problem.

1. Four solutions to the problem of operation accuracy

Previously mentioned in JS integer operation is no problem, then the floating point number to expand the corresponding integer multiple, converted into integer in the calculation, the calculation is reduced to integer multiple can not solve this problem yao. The plan is indeed feasible, but how to implement the plan, but need to be considered. The e first thought is multiplication, 512.06*100 can be converted into 51206, however goose.

Take the number as a string and manually shift the decimal point

The idea of the solution is like this. The specific code is relatively complex to write. I refer to the function on the Internet to integrate an NPM package. The general idea is introduced above, the specific code implementation can refer to the source code (if you can by the way point a like, that is the best)

2. ToFixed solutions

ToFixed’s scheme is relatively better to solve, as long as there is no problem with the precision of the four operations, rounding as long as the direct judgment of floating points need accurate number is greater than 5, the specific code implementation can also refer to the source code.

Four,

The core point of the solution is to use the string to solve the decimal point accuracy problem, although the implementation is a little complex, need to consider more cases, but it is really the safest approach. If you need high precision business scenarios can directly install my encapsulated NPM package, you can directly use the tutorial reference github oh!

Finally, if this post helped you in any way, feel free to click “Like”!

(Purely personal manual typing, there is a hand error or technical errors, certainly a lot of corrections!)