Why is 9999999999999999 converted to 10000000000000000 in JavaScript?

Question

Can any one explain to me why 9999999999999999 is converted to 10000000000000000?

alert(9999999999999999); //10000000000000000

http://jsfid

Answer 1

9999999999999999 is treated internally in JavaScript as a floating-point number. It cannot be accurately represented in IEEE 754 double precision as it would require 54 bits of precision (the number of bits is log2(9999999999999999) = 53,150849512... and since fractional bits do not exist, the result must be rouned up) while IEEE 754 provides only 53 bits (1 implict bit + 52 explicitly stored bits of the mantissa) - one bit less. Hence the number simply gets rounded.

Since only one bit is lost in this case, even 54-bit numbers are exactly representable, since they nevertheless contain 0 in the bit, which gets lost. Odd 54-bit numbers are rounded to the nearest value that happens to be a doubled even 53-bit number given the default unbiased rounding mode of IEEE 754.

Answer 2

1. JavaScript only has floating point numbers, no integers.

2. Read What Every Computer Scientist Should Know About Floating-Point Arithmetic.

   Summary: floating point numbers include only limited precision, more than 15 digits (or so) and you'll get rounding.

Answer 3

Why 9999999999999999 is converted to 10000000000000000 ?

All numbers in JavaScript are stored in 64-bit format IEEE-754, also known as “double precision”, So there are exactly 64 bits to store a number: 52 of them are used to store the digits, 11 of them store the position of the decimal point (they are zero for integer numbers), and 1 bit is for the sign.

If a number is too big, it would overflow the 64-bit storage, potentially giving an infinity:

alert( 1e500 );  
// Result => Infinity
// "e" multiplies the number by 1 with the given zeroes count.

If we check whether the sum of 0.1 and 0.2 is 0.3, we get false.

alert( 0.1 + 0.2 == 0.3 )

Strange! What is it then if not 0.3? This happens because, A number is stored in memory in its binary form, a sequence of ones and zeroes. But fractions like 0.1, 0.2 that look simple in the decimal numeric system are actually unending fractions in their binary form.

In other words, what is 0.1? It is one divided by ten 1/10, one-tenth. In decimal numeral system such numbers are easily re-presentable. Compare it to one-third: 1/3. It becomes an endless fraction 0.33333(3).

There’s just no way to store exactly 0.1 or exactly 0.2 using the binary system, just like there is no way to store one-third as a decimal fraction.

The numeric format IEEE-754 solves this by rounding to the nearest possible number. These rounding rules normally don’t allow us to see that “tiny precision loss”, so the number shows up as 0.3. But beware, the loss still exists.

As you see :

alert( 9999999999999999 ); // shows 10000000000000000

This suffers from the same issue: a loss of precision. There are 64 bits for the number, 52 of them can be used to store digits, but that’s not enough. So the least significant digits disappear.

What is Really Happening behind 9999999999999999 to 10000000000000000 is :

JavaScript doesn’t trigger an error in such events. It does its best to fit the number into the desired format, but unfortunately, this format is not big enough.

Reference : https://javascript.info/number

You can also refer this SO Question, it includes the very detail about the JavaScript Numbers.

Answer 4

Javascript doesn't have integers, only 64-bit floats - and you've ran out of floating-point precision.

See similar issue in Java: why is the Double.parseDouble making 9999999999999999 to 10000000000000000?

Answer 5

Question: Sometimes JavaScript computations seem to yield "inaccurate" results, e.g. 0.362*100 yields 36.199999999999996. How can I avoid this?

Answer: Internally JavaScript stores all numbers in double-precision floating-point format, with a 52-bit mantissa and an 11-bit exponent (the IEEE 754 Standard for storing numeric values). This internal representation of numbers may cause unexpected results like the above. Most integers greater than 253 = 9007199254740992 cannot be represented exactly in this format. Likewise, many decimals/fractions, such as 0.362, cannot be represented exactly, leading to the perceived "inaccuracy" in the above example. To avoid these "inaccurate" results, you might want to round the results to the precision of the data you used.

http://www.javascripter.net/faq/accuracy.htm