What is JavaScript's highest integer value tha

Question

Is this defined by the language? Is there a defined maximum? Is it different in different browsers?

Answer 1

>= ES6: Number.MIN_SAFE_INTEGER; Number.MAX_SAFE_INTEGER;

<= ES5

From the reference: Number.MAX_VALUE; Number.MIN_VALUE;

console.log('MIN_VALUE', Number.MIN_VALUE);
console.log('MAX_VALUE', Number.MAX_VALUE);

console.log('MIN_SAFE_INTEGER', Number.MIN_SAFE_INTEGER); //ES6
console.log('MAX_SAFE_INTEGER', Number.MAX_SAFE_INTEGER); //ES6

Answer 2

At the moment of writing, JavaScript is receiving a new data type: BigInt. It is a TC39 proposal at stage 3. BigInt has been shipped in Chrome and is underway in Node, Firefox, and Safari... It introduces numerical literals having an "n" suffix and allows for arbitrary precision:

var a = 123456789012345678901012345678901n;

Precision will still be lost, of course, when such a number is (maybe unintentionally) coerced to a number data type.

Answer 3

I did a simple test with a formula, X-(X+1)=-1, and the largest value of X I can get to work on Safari, Opera and Firefox (tested on OS X) is 9e15. Here is the code I used for testing:

javascript: alert(9e15-(9e15+1));

Answer 4

ECMAScript 6:

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

Answer 5

The short answer is “it depends.”

If you’re using bitwise operators anywhere (or if you’re referring to the length of an Array), the ranges are:

Unsigned: 0…(-1>>>0)

Signed: (-(-1>>>1)-1)…(-1>>>1)

(It so happens that the bitwise operators and the maximum length of an array are restricted to 32-bit integers.)

If you’re not using bitwise operators or working with array lengths:

Signed: (-Math.pow(2,53))…(+Math.pow(2,53))

These limitations are imposed by the internal representation of the “Number” type, which generally corresponds to IEEE 754 double-precision floating-point representation. (Note that unlike typical signed integers, the magnitude of the negative limit is the same as the magnitude of the positive limit, due to characteristics of the internal representation, which actually includes a negative 0!)

Answer 6

Many answers earlier show the result true of 9007199254740992 === 9007199254740992 + 1
to tell that 9 007 199 254 740 991 is the max safe integer.

What if we keep doing accumulation:

input: 9007199254740992 + 1  output: 9007199254740992  // expected: 9007199254740993
input: 9007199254740992 + 2  output: 9007199254740994  // expected: 9007199254740994
input: 9007199254740992 + 3  output: 9007199254740996  // expected: 9007199254740995
input: 9007199254740992 + 4  output: 9007199254740996  // expected: 9007199254740996

We could found out, among numbers greater than 9 007 199 254 740 992, only even numbers are representable.

It's an entry to explain how double-precision 64-bit binary format work on this. Let's look how 9 007 199 254 740 992 be held (represented) using this binary format.

We start from 4 503 599 627 370 496 with the brief version of format first:

  1 . 0000 ---- 0000  *  2^52            =>  1  0000 ---- 0000.  
     |-- 52 bits --|    |exponent part|        |-- 52 bits --|

On the left side of arrow, we have bit value 1, and a adjacent radix point, then by multiplying 2^52, we right move the radix point 52 steps, and it goes to the end. Now we get 4503599627370496 in binary.

Now we start to accumulate 1 to this value until all the bits are set to 1, which equals 9 007 199 254 740 991 in decimal.

  1 . 0000 ---- 0000  *  2^52  =>  1  0000 ---- 0000.  
                       (+1)
  1 . 0000 ---- 0001  *  2^52  =>  1  0000 ---- 0001.  
                       (+1)
  1 . 0000 ---- 0010  *  2^52  =>  1  0000 ---- 0010.  
                       (+1)
                        . 
                        .
                        .
  1 . 1111 ---- 1111  *  2^52  =>  1  1111 ---- 1111. 

Now, because that in double-precision 64-bit binary format, it strictly allots 52 bits for fraction, no more bit is available to carry for adding one more 1, so what we could do is setting all bits back to 0, and manipulate the exponent part:

  |--> This bit is implicit and persistent.
  |        
  1 . 1111 ---- 1111  *  2^52      =>  1  1111 ---- 1111. 
     |-- 52 bits --|                     |-- 52 bits --|

                          (+1)
                                     (radix point has no way to go)
  1 . 0000 ---- 0000  *  2^52 * 2  =>  1  0000 ---- 0000. * 2  
     |-- 52 bits --|                     |-- 52 bits --|

  =>  1 . 0000 ---- 0000  *  2^53 
         |-- 52 bits --| 

Now we get the 9 007 199 254 740 992, and with number greater than it, what the format could hold is 2 times of the fraction:

                            (consume 2^52 to move radix point to the end)
  1 . 0000 ---- 0001  *  2^53  =>  1 0000 ---- 0001.  *  2
     |-- 52 bits --|                |-- 52 bits --|

So when the number get to greater than 9 007 199 254 740 992 * 2 = 18 014 398 509 481 984, only 4 times of the fraction could be held:

input: 18014398509481984 + 1  output: 18014398509481984  // expected: 18014398509481985
input: 18014398509481984 + 2  output: 18014398509481984  // expected: 18014398509481986
input: 18014398509481984 + 3  output: 18014398509481984  // expected: 18014398509481987
input: 18014398509481984 + 4  output: 18014398509481988  // expected: 18014398509481988

How about number between [ 2 251 799 813 685 248, 4 503 599 627 370 496 )?

 1 . 0000 ---- 0001  *  2^51  =>  1 0000 ---- 000.1
     |-- 52 bits --|                |-- 52 bits  --|

The bit value 1 after radix point is 2^-1 exactly. (=1/2, =0.5) So when the number less than 4 503 599 627 370 496 (2^52), there is one bit available to represent the 1/2 times of the integer:

input: 4503599627370495.5   output: 4503599627370495.5  
input: 4503599627370495.75  output: 4503599627370495.5  

Less than 2 251 799 813 685 248 (2^51)

input: 2251799813685246.75   output: 2251799813685246.8  // expected: 2251799813685246.75 
input: 2251799813685246.25   output: 2251799813685246.2  // expected: 2251799813685246.25 
input: 2251799813685246.5    output: 2251799813685246.5

// If the digits exceed 17, JavaScript round it to print it.
//, but the value is held correctly:

input: 2251799813685246.25.toString(2) 
output: "111111111111111111111111111111111111111111111111110.01"
input: 2251799813685246.75.toString(2) 
output: "111111111111111111111111111111111111111111111111110.11"
input: 2251799813685246.78.toString(2)   
output: "111111111111111111111111111111111111111111111111110.11"

And what is the available range of exponent part? the format allots 11 bits for it. Complete format from Wiki: (For more details please go there)

So to gain 2^52 in exponent part we exactly need to set e = 1075.