blocks|key|3501545|text|Javascript没有整数，只有64位浮点数--而且你已经用完了浮点精度。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3501546|请参阅Java中的类似问题：why+is+the+Double.parseDouble+making+9999999999999999+to+10000000000000000?|offset|length|3501547|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/8907666/why-is-the-double-parsedouble-making-9999999999999999-to-10000000000000000?rq=1^0|0|E|23|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

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

See similar issue in Java: <a href="https://stackoverflow.com/questions/8907666/why-is-the-double-parsedouble-making-9999999999999999-to-10000000000000000?rq=1">why is the Double.parseDouble making 9999999999999999 to 10000000000000000?</a>

blocks|key|3984780|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3984781|JavaScript只有浮点数，没有整数。|ordered-list-item|3984782|3984783|3984784|Read+。|3984785|3984786|摘要:浮点数只包含有限的精度，超过15位(或更多)，您将进行舍入。|3984787|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|M|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|N|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|O|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|P|7|@]|8|@]|9|$]]|$1|F|3|G|4|C|6|Q|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|R|7|@]|8|@]|9|$]]|$1|I|3|J|4|5|6|S|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|T|7|@]|8|@]|9|$]]]|L|$]]

<ol>
<li>JavaScript only has floating point numbers, no integers.
</li>
<li>Read <a href="http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html" rel="noreferrer">What Every Computer Scientist Should Know About Floating-Point Arithmetic</a>.
Summary: floating point numbers include only limited precision, more than 15 digits (or so) and you'll get rounding.
</li>
</ol>

blocks|key|3501605|text|在JavaScript中，9999999999999999在内部被视为浮点数。它不能精确地用IEEE754双精度表示，因为它需要54位精度(位数是log2(9999999999999999)+=+53,150849512...由于分数位不存在，因此结果必须向上舍入)，而IEEE754仅提供53位(1个隐含位%2B+52个显式存储的尾数位)-少一个位。因此，这个数字只需进行四舍五入。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3501606|因为在这种情况下只丢失了一位，所以即使是54位的数字也是完全可以表示的，因为它们仍然在位中包含0，这会丢失。给定IEEE+754的默认无偏舍入模式，奇数54位数字被舍入为最接近的值，恰好是双倍偶数53位数字。|3501607|entityMap^0|D|G|0|1B|1|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

<code>9999999999999999</code> 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 <code>0</code> 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.

blocks|key|3984857|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3984858|+为什么将9999999999999999转换为10000000000000000+?|blockquote|offset|length|style|BOLD|3984859|3984860|3984861|JavaScript中的所有数都是以64位格式存储的IEEE-754，也称为“双精度”，所以正好有64位来存储数字：52位用于存储数字，11位用于存储小数点的位置(对于整数，它们是零)，和1位用于符号。|3984862|如果数字太大，它将溢出64位存储，可能会产生无穷大：|3984863|alert(+1e500+);++
//+Result+=>+Infinity
//+"e"+multiplies+the+number+by+1+with+the+given+zeroes+count.|code-block|syntax|javascript|3984864|如果我们检查0.1和0.2的和是否为0.3，我们得到的结果是false。|3984865|alert(+0.1+%2B+0.2+==+0.3+)|3984866|奇怪！如果不是0.3，那它是什么？，发生这种情况是因为，A数字以其二进制形式存储在内存中，这是一个由1和0组成的序列。但是像0.1，0.2这样在十进制数字系统中看起来很简单的分数实际上是它们的二进制形式的不结束的分数。|3984867|换句话说，什么是0.1？它是一除以十个1/10，十分之一。在十进制数系统中，这样的数字很容易重新表示。与三分之一相比:+1/3。它变成了一个无穷无尽的分数0.33333(3)。|3984868|使用二进制系统无法精确存储0.1或0.2，就像无法将三分之一存储为小数一样。|3984869|这些舍入规则通常不允许我们看到“微小的精度损失”，所以数字显示为0.3。但要注意，损失仍然存在。|3984870|如您所见的+:|3984871|alert(+9999999999999999+);+//+shows+10000000000000000|3984872|这也有同样的问题:精度的损失。有64位的数字，其中52位可以用来存储数字，但是不够的。所以最低有效位消失了。|3984873|3984874|++9999999999999999到10000000000000000背后真正发生的事情是:|3984875|3984876|3984877|在此类事件中，JavaScript不会触发错误。它会尽最大努力使数字符合所需的格式，但不幸的是，此格式不够大。|3984878|参考:+https://javascript.info/number|3984879|您也可以参考此，它包含有关JavaScript编号的详细信息。|3984880|entityMap|0|LINK|mutability|MUTABLE|url|https://javascript.info/number^0|0|1|16|0|0|0|E|K|1M|K|2L|7|0|0|0|0|0|0|31|0|0|2G|0|0|12|0|0|1C|0|0|7|0|0|0|F|G|3|12|G|0|0|1|1A|0|0|0|7|1C|0|0|3|4|U|0|0|0^^$0|@$1|2|3|-4|4|5|6|1T|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|1U|7|@$D|1V|E|1W|F|G]]|8|@]|9|$]]|$1|H|3|-4|4|5|6|1X|7|@]|8|@]|9|$]]|$1|I|3|-4|4|5|6|1Y|7|@]|8|@]|9|$]]|$1|J|3|K|4|5|6|1Z|7|@$D|20|E|21|F|G]|$D|22|E|23|F|G]|$D|24|E|25|F|G]]|8|@]|9|$]]|$1|L|3|M|4|5|6|26|7|@]|8|@]|9|$]]|$1|N|3|O|4|P|6|27|7|@]|8|@]|9|$Q|R]]|$1|S|3|T|4|5|6|28|7|@]|8|@]|9|$]]|$1|U|3|V|4|P|6|29|7|@]|8|@]|9|$Q|R]]|$1|W|3|X|4|5|6|2A|7|@$D|2B|E|2C|F|G]]|8|@]|9|$]]|$1|Y|3|Z|4|5|6|2D|7|@$D|2E|E|2F|F|G]]|8|@]|9|$]]|$1|10|3|11|4|5|6|2G|7|@$D|2H|E|2I|F|G]]|8|@]|9|$]]|$1|12|3|13|4|5|6|2J|7|@$D|2K|E|2L|F|G]]|8|@]|9|$]]|$1|14|3|15|4|5|6|2M|7|@$D|2N|E|2O|F|G]]|8|@]|9|$]]|$1|16|3|17|4|P|6|2P|7|@]|8|@]|9|$Q|R]]|$1|18|3|19|4|5|6|2Q|7|@$D|2R|E|2S|F|G]|$D|2T|E|2U|F|G]|$D|2V|E|2W|F|G]]|8|@]|9|$]]|$1|1A|3|-4|4|5|6|2X|7|@]|8|@]|9|$]]|$1|1B|3|1C|4|C|6|2Y|7|@$D|2Z|E|30|F|G]]|8|@]|9|$]]|$1|1D|3|-4|4|5|6|31|7|@]|8|@]|9|$]]|$1|1E|3|-4|4|5|6|32|7|@]|8|@]|9|$]]|$1|1F|3|1G|4|5|6|33|7|@$D|34|E|35|F|G]]|8|@]|9|$]]|$1|1H|3|1I|4|5|6|36|7|@$D|37|E|38|F|G]]|8|@$D|39|E|3A|1|3B]]|9|$]]|$1|1J|3|1K|4|5|6|3C|7|@]|8|@]|9|$]]|$1|1L|3|-4|4|5|6|3D|7|@]|8|@]|9|$]]]|1M|$1N|$4|1O|1P|1Q|9|$1R|1S]]]]

<blockquote>
 Why 9999999999999999 is converted to 10000000000000000 ?
</blockquote>

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: 

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

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

<pre><code>alert( 0.1 + 0.2 == 0.3 )
</code></pre>

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 : 

<pre><code>alert( 9999999999999999 ); // shows 10000000000000000
</code></pre>

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.

<blockquote>
 What is Really Happening behind 9999999999999999 to 10000000000000000 is :
</blockquote>

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 : <a href="https://javascript.info/number" rel="noreferrer">https://javascript.info/number</a>

You can also refer this <a href="https://stackoverflow.com/questions/307179/what-is-javascripts-highest-integer-value-that-a-number-can-go-to-without-losin">SO Question</a>, it includes the very detail about the JavaScript Numbers.

blocks|key|3984836|text|问:有时JavaScript计算似乎会产生“不准确”的结果，例如0.362*100会产生36.199999999999996。我怎样才能避免这种情况？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3984837|答:在内部，JavaScript以双精度浮点格式存储所有数字，尾数为52位，指数为11位(存储数值的IEEE754标准)。数字的这种内部表示可能会导致像上面这样的意外结果。大多数大于253+=+9007199254740992的整数不能用这种格式精确表示。同样，许多小数/小数，如0.362，不能精确表示，导致上面例子中感知到的“不准确”。为了避免这些“不准确”的结果，您可能希望将结果舍入到您使用的数据的精度。|3984838|http://www.javascripter.net/faq/accuracy.htm|offset|length|3984839|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|18|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@$F|R|G|S|1|T]]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|E]]]]

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.

<a href="http://www.javascripter.net/faq/accuracy.htm" rel="nofollow">http://www.javascripter.net/faq/accuracy.htm</a>

blocks|key|153299|text|二进制形式的9999999999999999是100011100001101111001001101111110000001111111111111111，它有54位数字。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|153300|153301|下面我们将把这个数字转换成Javascript+IEEE-754，它有1个数字代表符号，11个数字代表二进制偏移格式的尾数，52个数字代表数字本身。|blockquote|153302|153303|153304|在二进制形式中，第一个数字始终是IEEE1，因此Javascript在保存为IEEE754格式时省略尾数中数字的第一个数字。因此，我们将对尾数使用00011100001101111001001101111110000001111111111111111，它是53位数字，而对于只能保留52位的数字，我们将去掉最后一位数字0001110000110111100100110111111000001000000000000000进行舍入|153305|二进制形式的最终数字将是1+0001110000110111100100110111111000001000000000000000+0，而十进制形式的数字是10000000000000000|153306|尾数1是未写入尾数中的52位的第一位，然后是尾数的52位，然后是一个0，使其返回54位，这是十进制的10000000000000000|153307|153308|除非您阅读此beautiful+article，否则可能很难理解|153309|entityMap|0|LINK|mutability|MUTABLE|url|https://indepth.dev/posts/1139/here-is-what-you-need-to-know-about-javascripts-number-type#why-0-1-0-2-is-not-0-3^0|6|G|N|1I|0|0|0|0|0|21|1H|4G|1G|0|E|1G|0|1E|H|0|0|6|H|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@$9|13|A|14|B|C]|$9|15|A|16|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|17|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|18|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|19|8|@]|D|@]|E|$]]|$1|K|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|1B|8|@$9|1C|A|1D|B|C]|$9|1E|A|1F|B|C]]|D|@]|E|$]]|$1|N|3|O|5|6|7|1G|8|@$9|1H|A|1I|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1J|8|@$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|R|3|-4|5|6|7|1M|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|1N|8|@]|D|@$9|1O|A|1P|1|1Q]]|E|$]]|$1|U|3|-4|5|6|7|1R|8|@]|D|@]|E|$]]]|V|$W|$5|X|Y|Z|E|$10|11]]]]

9999999999999999 in binary form is 100011100001101111001001101111110000001111111111111111
which has 54 digits.
<blockquote>
Below we will convert this figure to Javascript IEEE-754 which has 1 digit for sign,
11 digits for mantissa in binary offset format and 52 signs for the
number itself.
</blockquote>
In binary form the first digit is always 1 so Javascript omits the first digit of the number in mantissa when saving to IEEE-754 format.
So, we will have 00011100001101111001001101111110000001111111111111111 for mantissa, which is 53 digits and as for the number we can keep only 52 digits we round the number removing last digit 0001110000110111100100110111111000001000000000000000
the final number in binary form will be 1 0001110000110111100100110111111000001000000000000000 0 which in decimal form is 10000000000000000
<blockquote>
1 is the first digit that is not written to 52 bits in mantissa, then
52 bits of mantissa and one 0 to make it 54 digits back which is
10000000000000000 in decimal
</blockquote>
That might be hard to understand unless you read this <a href="https://indepth.dev/posts/1139/here-is-what-you-need-to-know-about-javascripts-number-type#why-0-1-0-2-is-not-0-3" rel="nofollow noreferrer">beautiful article</a>

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

<pre><code>alert(9999999999999999); //10000000000000000
</code></pre>

<a href="http://jsfiddle.net/Y2Vb2/" rel="noreferrer">http://jsfiddle.net/Y2Vb2/</a>

Why is 9999999999999999 converted to 10000000000000000 in JavaScript?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

谁能给我解释一下为什么9999999999999999会被转换成10000000000000000？alert(9999999999999999); //10000000000000000

问为什么在JavaScript中将9999999999999999转换为10000000000000000？
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么在JavaScript中将9999999999999999转换为10000000000000000？EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么在JavaScript中将9999999999999999转换为10000000000000000？
EN