The backend asks why the frontend numerical precision is lost?

This article mainly includes Accuracy loss scenarios, reasons for accuracy loss, solutions and other aspects. If there is anything incorrect in the article, please share your opinions in the comment area.

Some friends said that this problem of loss of accuracy is related to basic content, or even content that has been published in college textbooks for a long time, or that a back-end developer cannot not know, and it is very headline-grabbing. I can only say It is right in your position (~It would be wrong to leave this position aside~).

Because not everyone has learned computer-related knowledge in college, or they have entered the software development industry through career changes, training, etc., this group of people may not have that much understanding of these so-called basic knowledge. Once this is in place, if you look at the title of this article based on this standpoint, you won’t be so angry.

Calculation of floating point numbers

Numerical calculations are still widely used in front-end applications, but when floating point numbers are involved in calculations, precision may be lost, as follows:

Add (+)

• Normal calculation:0.1 + 0.2 = 0.3

• JavaScript Calculation: 0.1 + 0.2 = 0.30000000000000004

Minus (-)

• Normal calculation: 1 - 0.9 = 0.1

• JavaScript Calculation: 1 - 0.9 = 0.09999999999999998

Multiply(*)

• Normal calculation:0.0532 * 100 = 5.32

• JavaScript Calculation: 0.0532 * 100 = 5.319999999999999

Except (/)

• Normal calculation: 0.3 / 6 = 0.05

• JavaScript Calculation: 0.3 / 6 = 0.049999999999999996

Exceeds the maximum value

The so-called exceeding the maximum value (maximum and minimum value) refers to exceeding Number.MIN_SAFE_INTEGER (- 9007199254740991), that is, + ( 2^53 – 1) or Number.MAX_SAFE_INTEGER (+ 9007199254740991), that is, a value in the range of - (2^53 – 1), which is the most common in the project The following situations are:

• The value returned by the backend exceeds the maximum value

  • Example 1: The list data returned by the backend usually has a corresponding ID to identify uniqueness, but the backend generates this ID is of Long type, then the value is likely to exceed the largest positive integer that can be represented in JavaScript. At this time, the accuracy will be lost, that is, the ID value actually obtained by the front end and the one returned by the back end will be inconsistent.

  • Example 2: The backend may need to calculate some values and then return the corresponding result value to the frontend. At this time, if the value exceeds the maximum, there will also be a loss of accuracy.

• When the front end performs numerical calculations, the calculation result exceeds the maximum value

  

Keep specified decimal places

In addition to the above scenarios involving floating point calculations that exceed the maximum value, we usually also process the numerical value to retain specified decimal places, and some developers may directly use Number.prototype.toFixed To achieve, but this method does not guarantee the results we expect. For example, when retaining decimal places, there will be problems when rounding is required, as follows:

console.log(1.595.toFixed(2))
console.log(1.585.toFixed(2))
console.log(1.575.toFixed(2))
console.log(1.565.toFixed(2))
console.log(1.555.toFixed(2))
console.log(1.545.toFixed(2))
console.log(1.535.toFixed(2))
console.log(1.525.toFixed(2))
console.log(1.515.toFixed(2))
console.log(1.505.toFixed(2))

The computer can actually only store/recognize **binary** internally, so documents, pictures, numbers, etc. will be converted into Binary , and for numbers, although we see the representation result of Decimal, in fact, the underlying process will be Decimal and Binary mutual conversion, and this conversion process may cause precision loss, because converting decimal to binary may produce an infinite loop part, and actually Storage space is limited.

IEEE 754 standard

Number storage in Javascript uses the **Double precision floating point**[2] data type specified in **IEEE 754**[1], double precision floating point Points use 64 bits (8 bytes) to store a **floating point number**[3], which can represent 53 bits in binary Valid digits, i.e. (0-52 bits are 1) 111...111 = (53 bits are 1, 0-52 bits are 0) 1000...000 - 1, which is 2^53 - 1, and this is also Number.MAX_SAFE_INTEGER ( + 9007199254740991) corresponding value.

The composition of double-precision floating point numbers

Double precision floating point number (double) consists of the following parts:

• sign Sign bit, 0 is positive, 1 is negative

  • 1 bit at bit 63

• exponent The exponent part, representing the power of 2

  • Accounting for 11 bits, at bits 52-62

  • The exponent uses the offset code representation, that is, the true value e of the exponent is added with an offset quantity, and then get the expand code (that is, the calculation result) and express it as a binary number

  • whereOffset = (2^n-1) - 1, n is the number of digits in theexponent (i.e. n = 11), so the offset is Math.pow(2, 11-1) - 1 = 1023

  • Exponent code E = Exponent true value e + Offset code (2^n-1) - 1

  

• mantissa The mantissa part indicates the precision of floating point numbers

  • Accounting for 52 bits, in bits 0-51

  • The mantissa is expressed in an implicit way, that is, the highest bit of the mantissa always implies a 1 and is hidden in to the left of the decimal point (i.e. 1 < mantissa < 2), so the number of significant digits in the mantissa is 53 digits, not 52 Bit

(1.1341).toFixed(2) = '1.13'


(1.1361).toFixed(2) = '1.14'


(1.1351).toFixed(2) = '1.14'


(1.1350).toFixed(2) = '1.14'


(1.1050).toFixed(2) = '1.10'

(1.1051).toFixed(2) = 1.11 (correct √)
(1.105).toPrecision(17) = '1.1050000000000000'


(1.105).toFixed(2) = 1.10 (Correct √)


(1.125).toFixed(2) = 1.13 (Incorrect ×)
1.125.toPrecision(17) = '1.1250000000000000'


(1.145).toFixed(2) = 1.15 (Incorrect ×)
1.145.toPrecision(17) = '1.1450000000000000'


(1.165).toFixed(2) = 1.17 (Incorrect ×)
1.165.toPrecision(17) = '1.1650000000000000'


(1.185).toFixed(2) = 1.19 (Incorrect ×)
1.185.toPrecision(17) = '1.1850000000000001'

a. Let **n = `an integer`**, where **`n / 10^f - x`** is as close as possible to **`0`**, if there are two such * *n**, choose **larger n**

b. If **n = `integer0`**, then **m = `"0"`**, otherwise, **m = a string consisting of numbers in the `decimal` representation of `n` Values (in order, without leading zeros) `**

c. If **exponent f ≠ `0`**, then **k = `m.length`**

* If **k ≤ f**, then
    * **z = `string`** consisting of `f + 1-k` occurrences of code unit `0x0030(DIGIT ZERO)`
    * **m = `z + m`**
    * **k = `f + 1`**
* Let **a = the first `k-f` code unit of `m`**
* Let **b = the other `f` coding units of `m`**
* Set **m = `a + "." + b`**

Number.prototype.toFixed=function (d) {
    var s=this + "";
    if(!d)d=0;
    if(s.indexOf(".")==-1)s + =".";
    s + =new Array(d + 1).join("0");
    if(new RegExp("^(-|\ + )?(\d + (\.\d{0," + (d + 1) + "})?)\d*$") .test(s)){
        var s="0" + RegExp.$2,pm=RegExp.$1,a=RegExp.$3.length,b=true;
        if(a==d + 2){
            a=s.match(/\d/g);
            if(parseInt(a[a.length-1])>4){
                for(var i=a.length-2;i>=0;i--){
                    a[i]=parseInt(a[i]) + 1;
                    if(a[i]==10){
                        a[i]=0;
                        b=i!=1;
                    }else break;
                }
            }
            s=a.join("").replace(new RegExp("(\d + )(\d{" + d + "})\d$"),"$1.$2");
 
        }if(b)s=s.substr(1);
        return (pm + s).replace(/\.$/,"");
    }return this + "";
 
}