**After my discussion** of JavaScript’s numeric limitations when working with integers, I was curious. There must be some integer that’s the biggest one that JavaScript can represent.

A brute force method (my favorite kind) would simply increment a variable and see when it stops going up. Add one. Add one. Add one. Stuck.

That number is so large, though, that even I didn’t have the patience to wait for the loop to end. So I broke the problem up into two pieces.

First I set a variable to 1. I keep doubling it until I find a number that is the same as that number plus one. That’s my high limit and half that number is valid.

Then I do a binary search inside that range. The code looks like this:

a=1;
b=2;
//find one that fails
while (a!=b) {
old=a;
a+=a;
b=a+1;
}
//do binary search
low=old;
high=a;
while (high-low>1) {
mid=parseInt((low+high)/2,10);
a=mid;
b=a+1;
if (a==b) {
high=mid;
} else {
low=mid;
}
}
console.log(high);

The answer is 9007199254740992. Something over 9 quadrillion. Makes more sense why it would be a limit when you look at the number in hexadecimal. That’s 0x020000000000000.

That’s right. JavaScript can tell the difference between 9007199254740991 and 9007199254740992, but it thinks that 9007199254740992 and 9007199254740993 are the same. That falls out from the **IEEE-754 **double-precision floating-point spec that JavaScript uses to represent all numbers.

Remember that next time you want to write a for loop that counts to 10 quadrillion–it’s an infinite loop. You’ll never get there.

### Like this:

Like Loading...

*Related*

## alsanan said,

July 16, 2008 at 9:36 am

Nice number. Nice title for your post. Fortunately, I never make such a long loops. Sssh, don’t say this, but the user is waiting. ;-)

## Andrea Giammarchi said,

July 16, 2008 at 1:18 pm

Math.pow(2, 53) – 1 is the last reliable number for common operations.

You can still add 1, but you cannot add 2.

What I am trying to say, is that there are no odd numbers, like 9007199254740993, after Math.pow(2, 53)

Moreover, the common limit for daily JS usage, is Math.pow(2, 32)

For example, an Array cannot contain more than Math.pow(2, 32) elements, but it does not make sense, since we have no browsers that could quickly manage such big Array.

Math.pow(2, 31) is the limit for bit operations.

~myString.indexOf(“stuff”) will always works as expected, untile the index will be less than Math.pow(2, 31), but again is such a nonsense string to manage.

Same stuff for >> operator, up to tipical Math.pow(2, 31) limit.

Kind Regards

## Nosredna said,

July 16, 2008 at 3:24 pm

That’s a great point. I didn’t mean there were no more integers, I just wanted to show where things broke down if we treated JavaScript’s numbers as if they were integers.

And I wanted to show how we would look at the situation pragmatically if we didn’t know how the numbers were stored. That’s why I saved the mention of the IEEE spec for the end. People can go look up the spec to learn more.

Your points are interesting, especially concerning arrays and the .length property.

## Zeke said,

July 25, 2008 at 6:30 am

Heh, that’s a funny coincidence. I was googling for the number 9007199254740992 for a totally different reason — it happens to be the first power of two that starts with 9. Since that takes a surprisingly long time to happen, I was wondering if others around the web had discussed it.

## Nosredna said,

July 25, 2008 at 6:42 am

That’s the first power of two that starts with a 9? Weird.

I bet you find a fair number of google hits with any power of 2. Well, any power of 2 that someone is likely to be willing to type.

## Andrew said,

February 8, 2009 at 11:33 am

It is a funny thing that 9007199254740992 bits = 1 terrabyte and 9007199254740993 is 1 bit more!

## mmw said,

February 20, 2009 at 11:59 pm

Hi Andrea (Giammarchi), exactly anyway this is always a floating point precision story, anyway when I am running this on my hardware I have my own limitations MAXINT, we won’t try Math.pow(2, 32) associative Array :)

Nosredna your approach really sucks maybe a lack of math and a lack of basic programming knowledge, and what Andrea told you is not “interesting”, it’s what you have to learn, take his comment as course.

Kind Regards

## Nosredna said,

February 21, 2009 at 12:20 am

Thanks for commenting mmw, I will attempt to learn some math and basic programming.

## Matt said,

December 1, 2009 at 11:56 pm

@mmw Your comment really sucks, maybe a lack of manners and basic social skills, it’s what you have to learn, take *this* comment as course.

@Nosredna I too have just run into this problem drawing a Sierpinski triangle with javascript. I never studied CS or maths proper, if I had I might not have spent the last hour figuring out why my numbers go haywire after 9007199254740992! This stuff is fun to learn, thanks or the post!

## Martin said,

September 25, 2009 at 9:44 am

Once you find your number ‘a’ in the while loop, that should be the maximum number, right? if ‘a’ is higher than ‘high’ then you have a contradiction.

1. a, high are non-negative integers and assume [high + 1 = high] and [a >= high]

2. thus [high + n = high] for all non-negative integers n

3. [a - high >= 0] so [high + (a - high) = high] (by 2)

4. [high + (a - high) = a] so by 3, [a == high]

## Ben Cherry said,

November 14, 2009 at 10:49 pm

I was just curious about this as well, and was playing in the Firebug console with large numbers. Then I googled and found this.

Anyways, 9007199254740992 is not the largest number JavaScript can understand. The problem is that you can’t get any more precision than that. Try 90071992547409920, for example. It works, and is larger (10x). I think 9.007199254740992e+307 might be the biggest, but I haven’t verified this. Adding to it just leaves it the same, but adding another power of 10 makes it Infinity.

Oh, and I think you could write a 10 quadrillion for loop something like this:

var y = 10quadrillion;

for (var x = 0; x 10quadrillion/2) {

x = 0;

y = 10quadrillion/2;

}

}