16

The answer to this question may be painfully obvious but I can't find it in the Mozilla docs nor on Google from a cursory search.

If you have some code like this

Number.MAX_VALUE + 1; // Infinity, right?
Number.MIN_VALUE - 1; // -Infinity, right?

Then I would expect adding anything to Number.MAX_VALUE would push it over to Infinity. The result is just Number.MAX_VALUE spat right back at me.

However, when playing around in the Chrome JS console, I noticed that it didn't actually become Infinity until I added/subtracted enough:

Number.MAX_VALUE + Math.pow(100,1000); // now we hit Infinity
Number.MIN_VALUE - Math.pow(100,1000); // -Infinity at last

What is the explanation for this "buffer" between Number.MAX_VALUE and Infinity?

kennytm
  • 510,854
  • 105
  • 1,084
  • 1,005
Mark
  • 1,312
  • 1
  • 16
  • 33
  • There are several unintuitive behaviors with big and small numbers- try subtracting Number.MIN_VALUE from Number.MAX_VALUE, for one. – kennebec May 31 '12 at 16:51
  • Number.MIN_VALUE "is the number closest to 0, not the most negative number, that JavaScript can represent" [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MIN_VALUE](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MIN_VALUE) – Johann Echavarria Apr 26 '14 at 19:26

2 Answers2

20

Standardwise...

In ECMAScript, addition of two nonzero finite numbers is implemented as (ECMA-262 §11.6.3 "Applying the Additive Operators to Numbers"):

the sum is computed and rounded to the nearest representable value using IEEE 754 round-to-nearest mode. If the magnitude is too large to represent, the operation overflows and the result is then an infinity of appropriate sign.

IEEE-754's round-to-nearest mode specifies that (IEEE-754 2008 §4.3.1 "Rounding-direction attributes to nearest")

In the following two rounding-direction attributes, an infinitely precise result with magnitude at least bemax ( b − ½ b1-p ) shall round to ∞ with no change in sign; here emax and p are determined by the destination format (see 3.3). With:

  • roundTiesToEven, the floating-point number nearest to the infinitely precise result shall be delivered; if the two nearest floating-point numbers bracketing an unrepresentable infinitely precise result are equally near, the one with an even least significant digit shall be delivered
  • roundTiesToAway, the floating-point number nearest to the infinitely precise result shall be delivered; if the two nearest floating-point numbers bracketing an unrepresentable infinitely precise result are equally near, the one with larger magnitude shall be delivered.

ECMAScript does not specify which of the round-to-nearest, but it doesn't matter here because both gives the same result. The number in ECMAScript is "double", in which

  • b = 2
  • emax = 1023
  • p = 53,

so the result must be at least 21024 - 2970 ~ 1.7976931348623158 × 10308 in order to round to infinity. Otherwise it will just round to MAX_VALUE, because that is the closer than Infinity.

Notice that MAX_VALUE = 21024 - 2971, so you need to add at least 2971 - 2970 = 2970 ~ 9.979202 × 10291 in order to get infinity. We could check:

>>> Number.MAX_VALUE + 9.979201e291
1.7976931348623157e+308
>>> Number.MAX_VALUE + 9.979202e291
Infinity

Meanwhile, your Math.pow(100,1000) ~ 26643.9 is well beyond 21024 - 2970. It is already infinity.

Community
  • 1
  • 1
kennytm
  • 510,854
  • 105
  • 1,084
  • 1,005
  • 1
    Great explanation straight from IEEE-754! I need to get around to reading that spec...maybe when I have trouble falling asleep. – Mark May 31 '12 at 18:55
  • 2
    @Mark: I find the IEEE 754 standard to be short and friendly, as standards go. For dealing with serious insomnia, I recommend reading the Unicode standard instead. :-) – Mark Dickinson May 31 '12 at 19:13
  • So round-to-nearest *does* come into it? I feel silly deleting my answer now. ;-) – T.J. Crowder May 31 '12 at 20:48
  • 1
    @T.J.Crowder: [Because there's no ``](http://meta.stackexchange.com/questions/40035/allow-the-small-tag). – kennytm Jun 01 '12 at 05:37
  • @kennytm, from the question: _Number.MIN_VALUE - 1; // -Infinity, right?_ - is my understanding correct that this should not be treated as overflow, it's underflow, and should not evaluate to `-Infinity`, but to `0` according to IEEE-754 standard? – Max Koretskyi Oct 16 '16 at 11:01
  • @Maximus: `Number.MIN_VALUE` is `5e-324`, it is the minimum *positive* value. The result is just `-1`. – kennytm Oct 16 '16 at 11:34
12

If you look at Number.MAX_VALUE.toString(2), you'll see that the binary representation of MAX_VALUE is 53 ones followed by 971 zeros. This because IEEE 754 floating points are made of a mantissa coefficient multiplied by a power of 2 (so the other half of the floating point number is the exponent). With MAX_VALUE, both the mantissa and the exponent are maxed out, so you see a bunch of ones bit-shifted up a lot.

In short, you need to increase MAX_VALUE enough to actually affect the mantissa, otherwise your additional value gets lost and rounded out.

Math.pow(2, 969) is the lowest power of 2 that will not tip MAX_VALUE into Infinity.

apsillers
  • 112,806
  • 17
  • 235
  • 239
  • 1
    +1, was just pointing that out in mine as well. In fact, I think this is the better answer by far. – T.J. Crowder May 31 '12 at 16:54
  • 1
    Thanks! (To clarify for future viewers, @T.J. was comparing against his own (now deleted) answer, not against Kenny's new answer, which is quite good.) – apsillers May 31 '12 at 17:16
  • 1
    +1 for giving the exact point that "tips" `MAX_VALUE` to `Infinity`. – Mark May 31 '12 at 18:49