NaN is the only value that is not equal to itself:

> NaN === NaN
false

Strict equality (===) is also used by Array.prototype.indexOf. You therefore can’t search for NaN in an array via that method:

> [ NaN ].indexOf(NaN)
-1

If you want to check whether a value is NaN, you have to use the global function isNaN():

> isNaN(NaN)
true
> isNaN(33)
false

However, isNaN does not work properly with nonnumbers, because it first converts those to numbers. That conversion can produce NaN and then the function incorrectly returns true:

> isNaN('xyz')
true

Thus, it is best to combine isNaN with a type check:

function myIsNaN(value) {
    return typeof value === 'number' && isNaN(value);
}

Alternatively, you can check whether the value is unequal to itself (as NaN is the only value with this trait). But that is less self-explanatory:

function myIsNaN(value) {
    return value !== value;
}

Note that this behavior is dictated by IEEE 754. As noted in Section 7.11, “Details of comparison predicates”:^[15]

How large a number’s magnitude can become is determined by its internal representation (as discussed in The Internal Representation of Numbers), which is the arithmetic product of:

The exponent must be between (and excluding) −1023 and 1024. If the exponent is too small, the number becomes 0. If the exponent is too large, it becomes Infinity. 2¹⁰²³ can still be represented, but 2¹⁰²⁴ can’t:

> Math.pow(2, 1023)
8.98846567431158e+307
> Math.pow(2, 1024)
Infinity

Dividing by zero produces Infinity as an error value:

> 3 / 0
Infinity
> 3 / -0
-Infinity

You get the error result NaN if you try to “neutralize” one Infinity with another one:

> Infinity - Infinity
NaN
> Infinity / Infinity
NaN

If you try to go beyond Infinity, you still get Infinity:

> Infinity + Infinity
Infinity
> Infinity * Infinity
Infinity

Strict and lenient equality work fine for Infinity:

> var x = Infinity;
> x === Infinity
true

Additionally, the global function isFinite() allows you to check whether a value is an actual number (neither infinite nor NaN):

> isFinite(5)
true
> isFinite(Infinity)
false
> isFinite(NaN)
false

JavaScript goes to great lengths to hide the fact that there are two zeros. Given that it normally doesn’t matter that they are different, it is recommended that you play along with the illusion of the single zero. Let’s examine how that illusion is maintained.

In JavaScript, you normally write 0, which means +0. But -0 is also displayed as simply 0. This is what you see when you use a browser command line or the Node.js REPL:

> -0
0

That is because the standard toString() method converts both zeros to the same '0':

> (-0).toString()
'0'
> (+0).toString()
'0'

Equality doesn’t distinguish zeros, either. Not even ===:

> +0 === -0
true

Array.prototype.indexOf uses === to search for elements, maintaining the illusion:

> [ -0, +0 ].indexOf(+0)
0
> [ +0, -0 ].indexOf(-0)
0

The ordering operators also consider the zeros to be equal:

> -0 < +0
false
> +0 < -0
false

How can you actually observe that the two zeros are different? You can divide by zero (-Infinity and +Infinity can be distinguished by ===):

> 3 / -0
-Infinity
> 3 / +0
Infinity

Another way to perform the division by zero is via Math.pow() (see Numerical Functions):

> Math.pow(-0, -1)
-Infinity
> Math.pow(+0, -1)
Infinity

Math.atan2() (see Trigonometric Functions) also reveals that the zeros are different:

> Math.atan2(-0, -1)
-3.141592653589793
> Math.atan2(+0, -1)
3.141592653589793

The canonical way of telling the two zeros apart is the division by zero. Therefore, a function for detecting negative zeros would look like this:

function isNegativeZero(x) {
    return x === 0 && (1/x < 0);
}

Here is the function in use:

> isNegativeZero(0)
false
> isNegativeZero(-0)
true
> isNegativeZero(33)
false

If you work with integers of up to 53 bits magnitude, you are fine. Unfortunately, you’ll often encounter 64-bit unsigned integers in programming (Twitter IDs, databases, etc.). These must be stored in strings in JavaScript. If you want to perform arithmetic with such integers, you need special libraries. There are plans to bring larger integers to JavaScript, but that will take a while.

ECMAScript 6 will provide the following constants:

Number.MAX_SAFE_INTEGER = Math.pow(2, 53)-1;
Number.MIN_SAFE_INTEGER = -Number.MAX_SAFE_INTEGER;

It will also provide a function for determining whether an integer is safe:

Number.isSafeInteger = function (n) {
    return (typeof n === 'number' &&
        Math.round(n) === n &&
        Number.MIN_SAFE_INTEGER <= n &&
        n <= Number.MAX_SAFE_INTEGER);
}

For a given value n, this function first checks whether n is a number and an integer. If both checks succeed, n is safe if it is greater than or equal to MIN_SAFE_INTEGER and less than or equal to MAX_SAFE_INTEGER.

How can we make sure that results of arithmetic computations are correct? For example, the following result is clearly not correct:

> 9007199254740990 + 3
9007199254740992

We have two safe operands, but an unsafe result:

> Number.isSafeInteger(9007199254740990)
true
> Number.isSafeInteger(3)
true
> Number.isSafeInteger(9007199254740992)
false

The following result is also incorrect:

> 9007199254740995 - 10
9007199254740986

This time, the result is safe, but one of the operands isn’t:

> Number.isSafeInteger(9007199254740995)
false
> Number.isSafeInteger(10)
true
> Number.isSafeInteger(9007199254740986)
true

Therefore, the result of applying an integer operator op is guaranteed to be correct only if all operands and the result are safe. More formally:

isSafeInteger(a) && isSafeInteger(b) && isSafeInteger(a op b)

implies that a op b is a correct result.

If the mask, the second operand, is 0, you don’t change any bits and the result is the first operand, coerced to a signed 32-bit integer. This is the canonical way to execute this kind of coercion and is used, for example, by asm.js (refer back to Is JavaScript Fast Enough?):

// Convert x to a signed 32-bit integer
function ToInt32(x) {
    return x | 0;
}

ToInt32() removes the fraction and applies modulo 2³²:

> ToInt32(1.001)
1
> ToInt32(1.999)
1
> ToInt32(1)
1
> ToInt32(-1)
-1
> ToInt32(Math.pow(2, 32)+1)
1
> ToInt32(Math.pow(2, 32)-1)
-1

The same trick that worked for bitwise Or also works for shift operators: if you shift by zero bits, the result of a shift operation is the first operand, coerced to a 32-bit integer. Here are some examples of implementing operations of the ECMAScript specification via shift operators:

// Convert x to a signed 32-bit integer
function ToInt32(x) {
    return x << 0;
}

// Convert x to a signed 32-bit integer
function ToInt32(x) {
    return x >> 0;
}

// Convert x to an unsigned 32-bit integer
function ToUint32(x) {
    return x >>> 0;
}

Here is ToUint32() in action:

> ToUint32(-1)
4294967295
> ToUint32(Math.pow(2, 32)-1)
4294967295
> ToUint32(Math.pow(2, 32))
0

You have to decide for yourself if the slight increase in efficiency is worth your code being harder to understand. Also note that bitwise operators artificially limit themselves to 32 bits, which is often neither necessary nor useful. Using one of the Math functions, possibly in addition to Math.abs(), is a more self-explanatory and arguably better choice.

The range of the radix is 2 ≤ radix ≤ 36. It determines the base of the number to be parsed. If the radix is greater than 10, letters are used as digits (case-insensitively), in addition to 0–9.

If radix is missing, then it is assumed to be 10, except if str begins with “0x” or “0X,” in which case radix is set to 16 (hexadecimal):

> parseInt('0xA')
10

If radix is already 16, then the hexadecimal prefix is optional:

> parseInt('0xA', 16)
10
> parseInt('A', 16)
10

So far I have described the behavior of parseInt() according to the ECMAScript specification. Additionally, some engines set the radix to 8 if str starts with a zero:

> parseInt('010')
8
> parseInt('0109')  // ignores digits ≥ 8
8

Thus, it is best to always explicitly state the radix, to always call parseInt() with two arguments.

Here are a few examples:

> parseInt('')
NaN
> parseInt('zz', 36)
1295
> parseInt('   81', 10)
81

> parseInt('12**', 10)
12
> parseInt('12.34', 10)
12
> parseInt(12.34, 10)
12

Don’t use parseInt() to convert a number to an integer. The last example gives us hope that we might be able to use parseInt() for converting numbers to integers. Alas, here is an example where the conversion is incorrect:

> parseInt(1000000000000000000000.5, 10)
1

The argument is first converted to a string:

> String(1000000000000000000000.5)
'1e+21'

parseInt doesn’t consider “e” to be an integer digit and thus stops parsing after the 1. Here’s another example:

> parseInt(0.0000008, 10)
8
> String(0.0000008)
'8e-7'

parseInt() shouldn’t be used to convert numbers to integers: coercion to string is an unnecessary detour and even then, the result is not always correct.

parseInt() is useful for parsing strings, but you have to be aware that it stops at the first illegal digit. Parsing strings via Number() (see The Function Number) is less forgiving, but may produce nonintegers.

Two common ways of computing a binary complement (or inverse) of a binary number are:

32-bit integers don’t have an explicit sign, but you can still encode negative numbers. For example, −1 can be encoded as the twos’ complement of 1: adding 1 to the result yields 0 (within 32 bits). The boundary between positive and negative numbers is fluid; 4294967295 (2³²−1) and −1 are the same integer here. But you have to decide on a sign when you convert such an integer from or to a JavaScript number, which has an explicit sign as opposed to an implicit one. Therefore, signed 32-bit integers are partitioned into two groups:

The highest bit is often called the sign bit. Accordingly, 4294967295, interpreted as a signed 32-bit integer, becomes −1 when converted to a JavaScript number:

> ToInt32(4294967295)
-1

ToInt32() is explained in 32-bit Integers via Bitwise Operators.

In the following examples, we work with binary numbers via the following two operations:

For the radix 10, toString() uses exponential notation (with a single digit before the decimal point) in two cases. First, if there are more than 21 digits before the decimal point of a number:

> 1234567890123456789012
1.2345678901234568e+21
> 123456789012345678901
123456789012345680000

Second, if a number starts with 0. followed by more than five zeros and a non-zero digit:

> 0.0000003
3e-7
> 0.000003
0.000003

In all other cases, a fixed notation is used.