When do you usually do need to pay attention to, if want to add the value of the two floating-point Numbers and his actual value is 0.8 to 0.79999... Need for processing!

CodePudding user response:

0.7999999999. ToFixed (1)

CodePudding user response:

This problem is explained may have a look my blog at https://blog.csdn.net/xsl510079027/article/details/86686551

CodePudding user response:

First of all, this is not the accuracy of JS itself problem, JS says he can't take this blame,
This is our computer itself, yes, you didn't listen to wrong, is the computer itself,
Our computer at the time of internal storage data coding, itself is not a precise figure 0.1 0.1, its error is small, so that the computer displays it into 0.1,
When our code at compile time by a computer, 0.1 will be computer decoding is a very similar with the real 0.1 itself internal encoding digital computer, which is 0.000110011001 1001... 0.2 and 0.3, the same, and so on is also a truth, also said that at the beginning of the computer is not, a tiny rounding errors have been produced, that is why we see the result is different from what we expected, the root causes of
Say so many, why such an outcome will be equal to 0.7999999999999999 in the end? This is because we use double-precision floating-point decimal part can only support 52 both infinite loop of a binary number, respectively at the 52nd truncation, eventually you'll get the results,
As for processing way, upstairs brother blog wrote toFixed, indeed, can so, emmm, but how little, in fact, I don't like this kind of method,
I personal solutions tend to view the data itself times 10 to the NTH power finally divided by n method to solve, because our computer in the binary can accurately express digits is limited and the denominator is the decimal multiples of 2, as a result of conversion, there is no floating point number rounding error ~

CodePudding user response:

reference 5 twist ink floor south response:

first of all, this is not the accuracy of JS itself problem, JS says he can't take this blame,
This is our computer itself, yes, you didn't listen to wrong, is the computer itself,
Our computer at the time of internal storage data coding, itself is not a precise figure 0.1 0.1, its error is small, so that the computer displays it into 0.1,
When our code at compile time by a computer, 0.1 will be computer decoding is a very similar with the real 0.1 itself internal encoding digital computer, which is 0.000110011001 1001... 0.2 and 0.3, the same, and so on is also a truth, also said that at the beginning of the computer is not, a tiny rounding errors have been produced, that is why we see the result is different from what we expected, the root causes of
Say so many, why such an outcome will be equal to 0.7999999999999999 in the end? This is because we use double-precision floating-point decimal part can only support 52 both infinite loop of a binary number, respectively at the 52nd truncation, eventually you'll get the results,
As for processing way, upstairs brother blog wrote toFixed, indeed, can so, emmm, but how little, in fact, I don't like this kind of method,
I personal solutions tend to view the data itself times 10 to the NTH power finally divided by n method to solve, because our computer in the binary can accurately express digits is limited and the denominator is the decimal multiples of 2, as a result of conversion, there is no floating point number rounding error ~

Thank you for your science