3

See snippet:

var num = "9223372036854775808";
document.write(num);
document.write("<br>");
document.write(parseInt(num, 10));

On running the code snippet, the first write yields:

9223372036854775808

and the third write yields:

9223372036854776000

But, I am only parsing the number in string form to number. Why does it give a still larger number?

I thought it might have to do something with limits of storage capacity, but then, why would it yield a larger number if it could not store the smaller?

I read this question: Why parsing a very large number to integer return 1 and the parseInt doc but they did not help much.

So, Why does parsing a large number, of string form, return a larger number?

Community
  • 1
  • 1
Gaurang Tandon
  • 6,504
  • 11
  • 47
  • 84

1 Answers1

1

The first result is fine as it is treated as a string.

In the second one, it crosses the value of int which is +/- 9007199254740992 ie, the maximum value which parseint can parse is 9007199254740992 and since your value 9223372036854775808 is larger than the maximum value. it is giving some garbage value.

As commented correctly by blunderboy it seems that that the reason could be this

The numbers in Javascript are 64 bit "double" precision which follow the IEE754 floating point. Sothe largest positive whole number that can therefore be accurately represented is 2^53 and the rest of the remaining bits are reserved for the exponent.

If you check the ECMA specs this has been explained.

Rahul Tripathi
  • 168,305
  • 31
  • 280
  • 331
  • ... and therefore is stored as a float, which has limited *precision* and not size, so it might be a bit over or a bit under. Note that `parseFloat(num)` gives exactly the same result. Note that the result has 16 significant digits, as would be expected from a JS float value. – Amadan May 15 '15 at 08:58
  • 2
    @Rahul Tripathi It is not some garbage value. parseInt is definitely using some Round off mechanism..e.g. Checkout `parseInt(9223372036854775108)` gives `9223372036854775000` – Sachin Jain May 15 '15 at 08:59
  • @blunderboy:- Updated that with most likely the reason of precision issue – Rahul Tripathi May 15 '15 at 09:05
  • have a look to [link](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER) – Nina Scholz May 15 '15 at 09:10
  • Just to clarify: 2^53 isn't the largest integer that can accurately be stored by a 64 bit floating point number (OP's example 9223372036854776000 is another example of a number that can be accurately represented as such), however 2^53 is the edge case after which only SOME integers can be represented as such (before 2^53 this is possible for EVERY integer). This leads to some strange cases where for example "9223372036854775200" will parse to "9223372036854775000" and "9223372036854775300" will parse to "9223372036854776000" (why wouldnt this parse to the closer value 9223372036854775000 too?) – Nils O May 15 '15 at 09:13
  • 2
    I just ran another test taking an number "714341252076979033" which gives me 714341252076979100 as output. https://jsfiddle.net/0hdoatkj/ . So I think when 714341252076979033 (0x9e9d9958274c359 in hex), it is getting assigned to the nearest representable double-precision value, which is 714341252076979072 (0x9e9d9958274c380). And when we try to print out the value, it is being rounded to 15 significant decimal digits, which gives 714341252076979100. – Rahul Tripathi May 15 '15 at 09:18