1, the number of long, in C # Legal long integer number in JavaScript unexpectedly ...
Look at the following lines of simple code:
Copy Code code as follows:
var a = 2010060612120909191; Id1 generated by Time
var B = 2010060612120909199; Id2 generated by Time
Alert (A = = B);
alert (a); Did you find anything amazing?
alert (b); The last few seem to be ...
Alert (number (a) = = number (b));
Alert (parseint (A,) = = parseint (b, 10));
Alert (parsefloat (a) = = Parsefloat (b));
You can copy the code and test it yourself locally. The result of the actual operation is that A and b are equal, and the pop-up is "true". Anyway, the first time a building pig encountered this situation, it was a bit of an accident. Then the building pig let two numbers pop up, this time unexpectedly found that the number changed to "2010060612120909300". Finally, we tested the Number,parseint and parsefloat functions associated with numbers, and the three results are still true.
Then the building pig adjusts the numeric type to a string type, as follows:
Code
Copy Code code 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,) = = parseint (b, 10));//?
Alert (parsefloat (a) = = Parsefloat (b));//?
The first three expected are fine, but the conversion to a numeric comparison still returns true.
Are the two numbers tested here that are not within the number of JavaScript? But why does the number that pops up change to "2010060612120909300" (The hundred digits are too weird)?
Google has no results, using the following function to compare the size of two long integer numbers:
Copy Code code as follows:
Number comparison size (two input is a string or numeric type, long number comparison)
function Comparenumber (Prevnum, Nextnum) {
if (isNaN (prevnum) | | | prevnum.length = = 0) {
throw new Error ("first input non-digit");
}
else if (isNaN (prevnum) | | prevnum.length = = 0) {
throw new Error ("second input non-digit");
}
var result = 0; Return result 0: Two equals 1: The first number is greater than the 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 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, with a decimal point, the choice of parseint
This question has been talked about in some JavaScript books. Look at the following code:
Copy Code code as follows:
var a = 0.000001;
var B = 0.0000001;
Alert (parseint (a));
Alert (parseint (b));
Alert (parseint (b, 10));/Is it the reason for not filling in the 10 system?
You may already know it. parseint (b) returned unexpectedly is 1! Then, replace A and B with a string test:
Copy Code code 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 the building pig ventured to speculate that the JavaScript processing number encountered in the beginning of the 0 is sometimes treated as octal. This thought, Kao, makes sense. But here we tested two floating-point numbers a and b that started with 0? Well, the building pig is really unexpected other reasons, had to produce strange results of the number B, and changed to parseint (b, 10) test, Halo, or 1. Then, the number and parsefloat of the building pigs were tested:
Copy Code code 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, this building pig seems to be close to discovering the truth. b after number and parsefloat, all pop up 1e-7, scientific counting method. It seems that the problem of octal system is really. Then the NC building pig took it for granted that as long as the first parseint number first ToString or string, the problem can be solved:
Copy Code code as follows:
var B = 0.0000001;
Alert (parseint (b.tostring (), 10));
Alert (parseint (String (b), 10));
Dizzy Ah, how is it still 1 this time? Change to the following or the same:
Copy Code code as follows:
var B = String (0.0000001);
Alert (parseint (b));
So, how do we get the whole octal parseint back to the scientific notation of numbers? With the development needs, there are functions in math that can help us achieve functionality easily:
Copy Code code 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 functions of javascript, you can refer to the documentation and do not repeat them here. Finally, I look forward to your valuable comments and suggestions.
