61

It seems to me that the code

console.log(1 / 0)

should return NaN, but instead it returns Infinity. However this code:

console.log(0 / 0)

does return NaN. Can someone help me to understand the reasoning for this functionality? Not only does it seem to be inconsistent, it also seems to be wrong, in the case of x / 0 where x !== 0

Bloodyaugust
  • 2,415
  • 8
  • 30
  • 46
  • 1
    http://stackoverflow.com/questions/3215120/why-javascript-says-that-a-number-is-not-a-number – PSL Sep 16 '13 at 22:26
  • 1
    There's a decent tutorial [here](http://javascript.info/tutorial/number-math) –  Sep 16 '13 at 22:27
  • 2
    There are an infinite number of zeroes in any number, so `x / 0 === Infinity` seems logical to me. – Ken Herbert Sep 16 '13 at 22:28

3 Answers3

41

Because that's how floating-point is defined (more generally than just Javascript). See for example:

Crudely speaking, you could think of 1/0 as the limit of 1/x as x tends to zero (from the right). And 0/0 has no reasonable interpretation at all, hence NaN.

Ty Mick
  • 75
  • 1
  • 7
Oliver Charlesworth
  • 260,367
  • 30
  • 546
  • 667
11

In addition to answers based on the mathematical concept of zero, there is a special consideration for floating point numbers. Every underflow result, every non-zero number whose absolute magnitude is too small to represent as a non-zero number, is represented as zero.

0/0 may really be 1e-500/1e-600, or 1e-600/1e-500, or many other ratios of very small values.

The actual ratio could be anything, so there is no meaningful numerical answer, and the result should be a NaN.

Now consider 1/0. It does not matter whether the 0 represents 1e-500 or 1e-600. Regardless, the division would overflow and the correct result is the value used to represent overflows, Infinity.

Lutz Lehmann
  • 23,321
  • 2
  • 19
  • 49
Patricia Shanahan
  • 25,433
  • 3
  • 36
  • 69
  • Language is important here. Small numbers are not represented as zero, and zero does not represent small numbers. This phrasing leads people to think incorrectly about floating-point approximations. Floating-point division may return zero for operations whose mathematical result is tiny, but that is because floating-point division is defined to return the representable value nearest the exact value, not because it is defined to approximately represent the quotient. Each floating-point value represents exactly one number, not an interval. – Eric Postpischil Sep 17 '13 at 15:20
  • 1
    @EricPostpischil Yes and no. Yes, IEEE 754 floating point arithmetic is well defined, with a definite result for each calculation, and a single value for each finite number. No, because that system, in isolation, would be useless. It gets its practical usefulness from its ability to produce, in many cases, good approximations to the result of a scientific or engineering calculation that is actually defined in terms of real number arithmetic. I'll think about how to reword my answer to distinguish properly between real number arithmetic and floating point arithmetic. – Patricia Shanahan Sep 17 '13 at 16:58
  • @PatriciaShanahan: The way I like to think of it is that a floating-point value represents something that will be regarded as an exact number "going forward", but in many cases will represent the result of an operation whose exact numerical result was within 1/2ulp of the forward-going value. If `a`, `b`, and `c` are within an order of magnitude of each other, and one wants to display the sum accurate to four significant figures, knowing that `a+b+c` will be a value within 1ppm of the correct one [actual precision in fact being better] may be more helpful than a precise error term. – supercat Sep 18 '13 at 18:20
5

I realize this is old, but I think it's important to note that in JS there is also a -0 which is different than 0 or +0 which makes this feature of JS much more logical than at first glance.

1 / 0 -> Infinity
1 / -0 -> -Infinity

which logically makes sense since in calculus, the reason dividing by 0 is undefined is solely because the left limit goes to negative infinity and the right limit to positive infinity. Since the -0 and 0 are different objects in JS, it makes sense to apply the positive 0 to evaluate to positive Infinity and the negative 0 to evaluate to negative Infinity

This logic does not apply to 0/0, which is indeterminate. Unlike with 1/0, we can get two results taking limits by this method with 0/0

lim h->0(0/h) = 0
lim h->0(h/0) = Infinity

which of course is inconsistent, so it results in NaN

Matthew Ciaramitaro
  • 1,154
  • 13
  • 27
  • Interesting, but incomplete. Think `lim h -> 0 (h / h)` . Since JS has positive and negative zeroes, there should also be a positive and a negative limit. Thus only 0/-0 and -0/0 should result in NaN. The others should be positive or negative infinity. Of course, the mathematician in me is still crying like a baby. – SMBiggs Mar 07 '19 at 19:49
  • @SMBiggs, why `lim h -> 0 (h / h)` and not `lim h -> 0 (2h / h)` (for instance)? There is no consistent result. – trincot Aug 24 '20 at 10:59
  • I the comment section I did not have room to include the infinite variations that yield the same result. Instead I used the simplest form I could think of that creates a graph of the shape (and limits) in question. – SMBiggs Aug 25 '20 at 12:38