Explanation of the difficulties of numerical types in JavaScript_javascript skills

1. The numbers are long. The legal long integer numbers in C# are actually... in JavaScript...
Look at the following simple lines of code:

Copy code The code is as follows:

var a = 2010060612120909191; //Id1 generated by time
var b = 2010060612120909199; //Generated by time Id2
alert(a == b);
//alert(a); //Any surprising findings?
//alert(b); //The last few digits look like...
//alert(Number(a) == Number(b));
//alert(parseInt(a, 10 ) == parseInt(b, 10));
//alert(parseFloat(a) == parseFloat(b));

You can copy the code and test it locally. The actual result of the operation is that a and b are equal, and "true" pops up. Anyway, Lou Zhu felt a little surprised when he encountered this situation for the first time. Then Lou Zhu let two numbers pop up respectively, and this time he accidentally found that the number had changed to "2010060612120909300". Finally, I tested the Number, parseInt and parseFloat functions related to numbers, and the three results were still true.
Then Louzhu adjusts the numeric type to the string type, as follows:
Code

Copy the code The code is as follows:

var a = "2010060612120909191"; //Id1 generated by time
var b = "2010060612120909199"; //Id2 generated by time
alert(a == b) ;//false
alert(a); //2010060612120909191
alert(b); //2010060612120909199
alert(Number(a) == Number(b)); //?
alert (parseInt(a, 10) == parseInt(b, 10));//?
alert(parseFloat(a) == parseFloat(b));//?

this The first three as expected are no problem, but the comparison converted into numeric type still returns true.
Are the two numbers tested here not within the numerical limit of JavaScript? But why did the pop-up number change to "2010060612120909300" (hundreds digits are too weird)?
After searching on my own to no avail, I used the following function to compare the size of two long integer numbers:

Copy code The code is as follows:

//Number comparison (two inputs are string or numeric types, long number type numeric comparison)
function compareNumber(prevNum, nextNum) {
if ( isNaN(prevNum) || prevNum.length == 0) {
throw new Error("The first input is not a number");
}
else if (isNaN(prevNum) || prevNum.length == 0) {
throw new Error("The second input is not a number");
}
var result = 0; //return result 0: two are equal 1: the first number is greater than Second -1: The second number is greater than the first
if (prevNum.length > nextNum.length) {
result ;
}
else if (prevNum.length < nextNum .length) {
result--;
}
else {
//The number of digits is the same
for (var i = 0; i < prevNum.length; i ) {
var charNum1 = prevNum.toString().charAt(i);
var charNum2 = nextNum.toString().charAt(i);
if (parseInt(charNum1) > parseInt(charNum2)) {
result ;
break;
}
else if (parseInt(charNum2) > parseInt(charNum1)) {
result--; >}
}
return result;
}


2. With a decimal point, the choice of parseInt
This issue has been discussed in some javascript books. Look at the code below:

Copy code The code is as follows: var a = 0.000001;

var b = 0.0000001;

alert(parseInt(a));
alert(parseInt(b));
//alert(parseInt(b, 10));//Is it because 10 was not filled in? The reason for the hexadecimal system


You may already know. parseInt(b) returns 1! Then, replace a and b with strings and test it:

Copy the code The code is as follows: var a = "0.000001";

var b = "0.0000001";

alert(parseInt(a));
alert(parseInt(b));


This time, both a and b return 0. This is the expected result we want. Then Lou Zhu made a bold guess. It is said that when JavaScript processes numbers starting with 0, they are sometimes treated as octal. This idea, kao, makes sense. But the two floating point numbers a and b we tested here both start with 0? Well, Lou Zhu really couldn't think of any other reasons, so he had to change the number b that produced the strange result to parseInt(b, 10) to test it. It was still 1. Then, Louzhu tested Number and parseFloat:

Copy the code The code is as follows:

var a = 0.000001;
var b = 0.0000001;
alert(Number(a));
alert(Number(b));//1e-7
alert(parseFloat(a));
alert(parseFloat(b)); //1e-7

Haha, Lou Zhu seems to be close to discovering the truth this time. bAfter Number and parseFloat, 1e-7 pops up, which is scientific notation. It seems that it is really an octal problem. Then nclouzhu took it for granted that the problem could be solved by first converting the number to be parseInt to String or String:

Copy code The code is as follows:

var b = 0.0000001;
alert(parseInt(b.toString(), 10));
alert(parseInt(String(b), 10));

Damn, why is it still 1 this time? Change it to the following and it will still be the same:

Copy the code The code is as follows:

var b = String (0.0000001);
alert(parseInt(b));

So, for this octal parseInt to return a number in scientific notation, how do we round it? According to development needs, there are functions in Math that can help us easily implement functions:

Copy code The code is as follows:

var b = 0.0000001;
alert(Math.floor(b));

As for the difference between the floor and ceil methods of the commonly used Math function in JavaScript, you can refer to the relevant documents , will not be described here. Finally, I look forward to your valuable comments and suggestions.