★ Disclaimer: Because some functions have not disclosed the algorithm, the following content is only my test and inference, and it is not guaranteed to be consistent with the facts.
=======================================
First look at a piece of code:
var num1 = math.round( 0.575*100 )
console.log( num1 );Results of the:
problem analysis:
1、0.575*100=57.5
2. Round 57.5 (decimals are discarded by default, and reserved to single digits), the result should be 58, but the actual result is 57. Obviously this is wrong.
So where is the problem? Let's analyze one by one, first look at two pictures:
The same is rounding to 57.5, why is the result different?
I think, in fact, the essence of these two 57.5s should be different.
Let's test it in depth:
These two values are still the same, and no tricky is found.
Go deeper and zoom in on these two values:
Haha, I found it, it's very obvious, the two values are different.
Knowledge point: Because of the computer's mechanism of processing values, which affects the accuracy, the result of the 57.5*100 calculation is actually not 57.5, but 57.49999999999999...
But why does aardio show 57.5?
Continue to look, look for the essence, and see why aardio will let us see the illusion of [two same values]?
After testing, it is found that when aardio displays the value, it will automatically round off from the 15th decimal place.
So, as long as your decimal places are less than 15 digits, there is no problem. Once it reaches 15 digits, the displayed value will be different from the actual value.
In order to continue to determine the problem of aardio rounding the 15th place, we further tested:
After twists and turns, the problem was discovered again. The last digit was 5, which was not moving forward. It has been rounded up.
Let's test whether math.round() is the same:
Uh, what's wrong?
This……! ! ? ?
There was a problem with math.round(), starting from the 10th position, it was messed up.
math.round() only supports the 9th decimal place? !
Numerical amplification test
It seems that there is such a possibility. Since the 10 digits are not accurate, then we will verify whether the 9 digits are accurate:
OK, continue to zoom in and see:
There is basically no problem.
It seems that math.round() itself has accuracy problems. Therefore, I want to rely on math.round() to handle the idea of 14 decimal places, which is not easy to realize.
in conclusion
Now that there are various unknown problems in math calculation, how can we finally ensure that the value we deal with is the same as the displayed value?
Originally, we only needed to round the value according to the above rules.
But since there is a problem with math.round(), and functions such as console.log are more than just rounding, I can only compromise and come up with two imperfect solutions.
1. Because console.log uses tostring() to turn a value into a string, and we don’t know how tostring works, we can only use the tostring function first, and then use the tonumber function to make a [value → string → value ] Of the transformation process. This ensures that the displayed value is the same as the real value.
2. Use math.round(,9) directly for processing. Although the number of decimal places after processing does not exceed 9 digits, this not only ensures the consistency with the displayed value, but also ensures the processing efficiency and accuracy as much as possible.
★ Suggestion:
For calculations involving decimals, try to round the calculation results, and convert possible inaccurate results into a fixed value with acceptable accuracy.
Inaccurate results such as:
0.1+0.1 = 0.20000000000000001 ;
0.575×100 = 57.499999999999993 ;
0.14×100 = 14.0000000000000002 ;
Generally, for such inaccurate results, the decimal part will be very long. It is recommended to round it to within 9 digits after the decimal point.
Such as:
math.round( 0.1+0.1 ,9 ) = 0.2 ;
math.round( 0.575×100 ,9 ) = 57.5 ;
math.round( 0.14×100 ,9 ) = 14 ;
The final effect is as follows:
