# NaN is Not a Math

A critique of the counter-claim that JavaScript's use of NaN errors is valid because it's 'math.'# NaN is Not a Math

This is a handy little article you can give to any JavaScript pro who tries to claim that `NaN`

(Not a Number) is "math" or "part of the IEEE standard." I demonstrate that JavaScript's use of NaN is neither math, nor is it even following the standard, which means "`NaN`

is math" is no defense of JavaScript's implementation.

## What is NaN

`NaN`

is a mechanism defined by the IEEE 754 standard for indicating and signaling Floating-Point Arithmetic exceptional conditions. From the standard it says:

1.1 Scope: This standard specifies formats and methods for floating-point arithmetic in computer systems—standard and extended functions with single, double, extended, and extendable precision—and recommends formats for data interchange. Exception conditions are defined and standard handling of these conditions is specified.

This is from the actual standard document and outlines what the standard says it applies to. The purpose of `NaN`

in the standard is to handle situations where some floating point *arithmetic* operation doesn't make sense, has a failure mode, or similar situation that "should...afford retrospective diagnostic information inherited from invalid or unavailable data and results."

In JavaScript you'll get a `NaN`

when you attempt something like these lines of code:

```
> 0 / 0
NaN
```

However, the problem with JavaScript's `NaN`

comes from the way JavaScript abuses `NaN`

for many things that shouldn't use it, and how there are no "signaling NaNs" or diagnostic information, so trapping the error where it matters is far too difficult. There's also the issue that `NaN`

is not math at all, but just part of some standard.

## 1. IEEE 754 is Not Math

So `NaN`

is "math" right? As in, established via a proof that has been peer reviewed in a journal of mathematics such that it is considered a piece of the field of mathematics? I can find the paper that establishes `NaN`

on the same footing as, say, Principia Mathematica or Gödel's Incompleteness Theorem? Right? That exists?

No? Well then, `NaN`

is *not* math.

The reason people use this defense against JavaScript's `NaN`

is they think something being "math" makes it impossible to question. "Math NaN" is an unassailable proof that once established can never be refuted, disproved, undone, countered, or hated. Worse yet, hating `NaN`

means you're an idiot who doesn't know math. By claiming "NaN is math" they're trying to defend *JavaScript's* use of `NaN`

as if it's on the same validity level as Gödel's Theorem, and you're an idiot for not knowing this.

This is a Fallacy of False Equivalence. `NaN`

is not the same as Gödel's Theorem just because they both have numbers in them. In fact, `NaN`

is based on a standard that is specifically designed to break real floating point arithmetic so that it can work in a discrete CPU that can't efficiently do symbolic operations. If you divide 1/3 in a computer it has to make some compromises to give you some kind of close-enough answer. But, a "close enough" answer is not what mathematics is all about. Real mathematics--the kind based on real peer reviewed proofs--is based on being as logically exact as humanly possible.

IEEE Floating Point math is *not* perfectly exact, and that means it's *also* not "math". It's a bastardization of math as a practical compromise to make 1/3 work in a computer.

### The Math and Bailey

Now, when you bring up this clearly obvious point that `NaN`

--and IEEE Floating Point--are not math you'll get a reply that attempts to move the discussion to a more reasonable claim. They'll say, "Well it's not math per-se but it *is* defined in a standard that we all use so..."

This rhetorical trick is called a motte-and-bailey. A "motte-and-bailey fallacy" is where someone advances a controversial position (the bailey), and when challenged, runs to a defensible narrowing of that position (the motte). Once they defend the easily defended safe motte position they come out claiming they defended the controversial bailey position.

In this case, the controversial stance is, *"JavaScript's use of NaN is irrefutable because it is mathematically the same as Gödel's Theorem."* When you challenge this position, because

`NaN`

is not math at all, they'll retreat to a more narrow claim that it's "Part of the IEEE Floating Point standard." It's easy to defend that `NaN`

is in the standard and JavaScript uses `NaN`

. That's an uncontroversial stating of a simple fact. Once they defend *that*position they'll then claim that the original claim of

`NaN`

being just as proven as Gödel's Theorem is still valid, even though all they did was make the uncontroversial claim that you can find `NaN`

in both IEEE 754 and JavaScript.Yet, until someone produces a proof, published in a prestigious journal of mathematics, that establishes IEEE math as equal to Gödel's Theorem then, nope, `NaN`

is not math.

## 2. Where's the Signal?

Alright, let's say the motte-and-bailey is working. Someone is retreating to the "It's in the IEEE standard" claim as a way to defend `NaN`

like it's Gödel's Theorem. Well then, JavaScript doesn't even follow the IEEE 754 standard.

The IEEE 754-2008 standard *requires* two types of `NaN`

: quiet `qNaN`

and signaling `sNaN`

. A `qNaN`

is what you get with JavaScript where the result of the operation turns into a `NaN`

value and the program continues running. A *signaling* `sNaN`

is intended to be a fault that aborts the current operation, much like an exception. The standard specifies exactly when to use each, but JavaScript doesn't have an `sNaN`

, only the quiet ones.

That's just one example of JavaScript not following the standard, which means the defense of `NaN`

with the claim that it's "IEEE Standard" is invalidated as well. If the "`NaN`

is (IEEE) math" crowd want to defend JavaScript's `NaN`

with the IEEE 754 standard then JavaScript better follow the standard exactly or else it's no defense at all.

### It's Standard or It's Not

Standards are documents created by companies to help integrate and sell their products. These standards are not sources of truth or forces of nature that can't be questioned. You can *totally* question standards, but more importantly, because these documents are not universal truths they should be applied *sparingly*. If you take the IEEE 754 standard and attempt to apply it to things not covered in the document then you're stepping outside of the standard and it *once again* cannot be used as a defense.

JavaScript tosses `NaN`

around like it's (not a) candy. All kinds of operations not covered in the IEEE 754 standard return `NaN`

. Parsing integers isn't in the standard, and yet:

```
> parseInt("what")
NaN
```

This is parsing an *integer*, not a floating point number. Parsing is not in IEEE 754, and parsing an *INTEGER* is not in the standard, so JavaScript should *not* return a `NaN`

. You can't claim JavaScript's abuse of `NaN`

is defensible with *"it's IEEE standard"* when JavaScript returns `NaN`

from operations not...*in* the standard.

## 3. Where's the Diagnostics?

The standard mentions that a `NaN`

should include diagnostic information that lets someone figure out what went wrong:

Quiet NaNs should, by means left to the implementer’s discretion, afford retrospective diagnostic information inherited from invalid or unavailable data and results. To facilitate propagation of diagnostic information contained in NaNs, as much of that information as possible should be preserved in NaN results of operations.

What do you get from a JavaScript `NaN`

? Not much. You can test for it with `isNaN`

, but you can't get useful information like, where it happened, what the operands were used, or anything else. You just get a random `NaN`

somewhere and have to root out where it went.

For JavaScript's `NaN`

to be conforming (and useful) it should include the source location where it was created, as well as information on the two operands. This could be defended by referring to the "by means left to the implementer's discretion", but this doesn't say "*at* the implementer's discretion". It says, "by means left to", which means diagnostic information is required, but the standard won't say *how* it should done.

Not only would source location and operand information make `NaN`

conform to the standard, but it's a change that JavaScript could make now that would *vastly* improve `NaN`

as well as be backward compatible with existing code. We could have additional functions on `Number`

that throw exceptions, get diagnostic information, etc.

## So What?

Finally, people have problems with `NaN`

, and trying discredit their confusion and frustration by proclaiming *"it's math bro"* is wrong. If I haven't convinced you that JavaScript's use of `NaN`

is not math, and not IEEE 754 compliant, then at a minimum you should realize that the way `JavaScript`

handles `NaN`

causes people problems, so the reply should at least be more sympathetic and educational than, "LOL learn math dood."

That's probably the biggest reason I wrote this essay. The claim that "NaN is math" is a classist insult that tries to shame people for not being good at math, when it's JavaScript's fault for not providing enough diagnostic information to make `NaN`

useful...as required by the *standard*.

**Stripe is Paypal circa 2010**

**Equal Height Holy Grail Layout in Modern CSS**

**Adding JavaScript Level 2 to Beginner Basics**

**Announcing Beginner Basics Full Release**

**A Frontend Development Process**

**See More...**