The numeric type in Javascript is really not that simple.

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 take a look at the following lines:Code:

Code

VaR A =   2010060612120909191 ; // Id1 generated by Time
VaR B =   2010060612120909199 ; // Id2 generated by Time
Alert ( = 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 were 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

VaR A =   " 2010060612120909191 " ; // Id1 generated by Time
VaR B =   " 2010060612120909199 " ; // Id2 generated by Time
Alert ( = B ); // False
Alert (); // 2010060612120909191
Alert (B ); // 2010060612120909199
Alert (number () = Number (B )); // ?
Alert (parseint (, 10 ) = Parseint (B, 10 )); // ?
Alert (parsefloat () = 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? Why is the pop-up number changed to"2010060612120909300"(Hundred digits are too strange )?
After Google's failure, we used the following function to compare the numbers of two long integers:

Code

// Number comparison size (two inputs are string or number type, and long numbers 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 ( " The second input is not a number. " );
}
VaR Result =   0 ; // Return result 0: two equal values. 1: the first digit is greater than the second digit.-1: the second digit is greater than the first digit.
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:

VaR A =   0.000001 ;
VaR B =   0.0000001 ;
Alert (parseint ());
Alert (parseint (B ));
// Alert (parseint (B, 10); // is it because the 10th hexadecimal format is not entered?

You may already know. Parseint (B) returns1! Then, replace A and B with a string to test:

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:

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:

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:

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:

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.