Difficult description of numeric type in javascript _ javascript skills

The following two small problems are encountered by Lou pig in actual project development. I will discuss them with you. 1. The number is long. The valid long integer number in c # Is In javascript ......
Let's look at the following simple code:

The Code is as follows:

Var a = 2010060612120909191; // The Id1 generated by Time
Var B = 2010060612120909199; // Id2 generated by Time
Alert (a = B );
// Alert (a); // are there any amazing discoveries?
// Alert (B); // The last few digits seem to be...
// 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 running result is that a and B are equal, and "true" is displayed ". I was surprised when Lou pig encountered this situation for the first time. Then Lou pig asked the two numbers to pop up separately. This time, the numbers unexpectedly changed to "2010060612120909300 ". Finally, we tested the Number, parseInt, and parseFloat functions related to the Number. The three results are still true.
Then Lou pig adjusted the numeric type to the string type as follows:
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 ));//?

The first three items in this prediction are correct. However, true is still returned if the comparison is converted to a numeric value.
Are the two numbers tested here not within the limit of javascript numbers? But why is the pop-up number changed to "2010060612120909300" (the hundred digits are so strange )?
After google's failure, we used the following function to compare the numbers of two long integers:

The Code is as follows:

// Compare the size of a number (two input values are string or number type, and long numeric values are compared)
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 ("second input is not a number ");
}
Var result = 0; // return result 0: two equal values 1: The first number is greater than the second-1: The second number is greater than the first one
If (prevNum. length> nextNum. length ){
Result ++;
}
Else if (prevNum. length <nextNum. length ){
Result --;
}
Else {
// Same number of digits
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 --;
Break;
}
}
}
Return result;
}

2. parseInt with a decimal point
Some javascript books have already mentioned this issue. See the following code:

The Code is as follows:

Var a = 0.000001;
Var B = 0.0000001;
Alert (parseInt ());
Alert (parseInt (B ));
// Alert (parseInt (B, 10); // is it the reason for not writing the 10th hexadecimal code?

You may already know. ParseInt (B) returns 1! Then, replace a and B with a string to test:

The Code is as follows:

Var a = "0.000001 ";
Var B = "0.0000001 ";
Alert (parseInt ());
Alert (parseInt (B ));

This time, both a and B return 0. This is the expected result. Lou pig boldly guessed that javascript processing numbers sometimes start with 0 as octal processing. Kao makes sense. But here we test two floating point numbers a and B both start with 0? Well, Lou pig really cannot think of other reasons, so I have to test the number B that generates strange results and change it to parseInt (B, 10), dizzy, or 1. Then, Lou pig tested the Number and parseFloat:

The Code is as follows:

Var a = 0.000001;
Var B = 0.0000001;
Alert (Number ());
Alert (Number (B); // 1e-7
Alert (parseFloat ());
Alert (parseFloat (B); // 1e-7

Haha, this time the pig seems to be close to discovering the truth. After the Number and parseFloat values of B, 1e-7 is displayed, which indicates scientific notation. It seems that it is still a problem of gossip. Then, the nc building pig assumes that the problem can be solved as long as the number of parseInt is toString or String first:

The Code is as follows:

Var B = 0.0000001;
Alert (parseInt (B. toString (), 10 ));
Alert (parseInt (String (B), 10 ));

Dizzy. How can this time be 1? The following is the same:

The Code is as follows:

Var B = String (0.0000001 );
Alert (parseInt (B ));

So, how can we get an integer for the octal parseInt that returns the number of scientific notation? According to the development needs, there are functions in Math that can help us easily implement the functions:

The Code is as follows:

Var B = 0.0000001;
Alert (Math. floor (B ));

For the differences between the floor and ceil methods of Math functions commonly used in javascript, refer to the relevant documentation. Finally, we look forward to your valuable comments and suggestions.