JS decimal addition problem

JS: 0.1＋0.2 will be equal to 0.30000000004

Note: The following is an early learning record without the original author, and it will be added when found.

The number type of JavaScript is in accordance with the JavaScript standard of ECMA, and its Number type is the double-precision value of IEEE 754, which is equivalent to the double type of java. The IEEE 754 standard "Binary Floating Point Arithmetic" (www.ieee.org) is a standard for computer encoding of real numbers. Therefore, the problem of precision is not unique to the JS language.

Whether recording values ​​on paper or on a computer, some encoding scheme must be used to express the values. It must be understood that the numerical value expressed by the code is not the numerical value itself, but only a human or computer understandable description of the numerical value. Any encoding scheme has its limitations, either in terms of representation range (precision) or other complexity constraints.

There is no absolutely perfect numerical encoding scheme, and the standard introduces a lot of compromises and compromises for ease of handling, as do algorithms built on this representation (such as division operations). Due to the "defects" in the numerical expression, the calculation results inevitably accumulate more and more errors.

The precision of floating-point numbers saved in IEEE 754 format is equivalent to a decimal fraction with 15, 16, or 17 decimal places, and the exact number of digits will vary due to binary-to-decimal conversion problems. To get the highest conversion precision, you must specify 17 decimal places - in which case the first 15 digits of precision can be trusted.

Are 0.1000000000000000000000000001 (28 decimal), 0.100000000000000000000000001 (27 decimal), .1000000000000000000000000456 (28 decimal), 0.09999999999999999999999 (23 decimal), the result is displayed: The following output values (not to output as a string) in JavaScript The value is 0.1. For another example, if you output a rational number expression of 1/3, the result is 0.3333333333333333.

Therefore, when JavaScript decimals do four arithmetic operations, the precision will be lost.
Of course, there are also some ways to ensure a certain precision: http://jiangzhengjun.iteye.com/blog/4...
Some people have also summarized some principles:

Principles
Most Web pages do not require decimals to avoid using decimals, try to use them as much as possible Integer. Make sure that the indices of the array are all integers. Calculate the amount in cents instead of dollars. Percentages are calculated 100 times larger to avoid decimals. Divide (/) and modulo (%) operations are avoided as much as possible, as they lead directly to floating-point numbers in most cases. If division must be used, immediately return to integer arithmetic with the Math.round method.

■ If floating-point numbers must be used, introduce redundant decimal places as much as possible—that is, add more decimal places in addition to the operation precision required by the program. If the program requires 5 digits of decimal precision, reserve at least 6 digits in the operation. Decimal, 8 bits is better. The more redundant bits, the smaller the effect of accumulated errors.

■ Avoid using too large or too small values ​​in the same expression. Subtraction or comparison of two very close numbers is error-prone. Adding a small number to a large number is a waste of time, and a small number is likely to be treated as 0. However, multiplying a very small number by a very large number is generally not a problem, e.g. 2 * 12345678 gives the correct result 24691356. However, the result for 0.1 - 0.09 is 0.010000000000000009.

■ Use isFinite() and isNaN() to check operation results Before submitting any numerical operation results through the form, be sure to check the validity of the data.

■ Use Numerical Operations with Care The fewer numerical operations a program involves, the less likely it is to introduce errors. Floating-point numbers are regarded as VIPs and cannot be driven arbitrarily.
(Original webpage https://segmentfault.com/q/1010000000137297)