beginner25 minby DevFox

Numbers and Floating Point

One number type for everything, the arithmetic that surprises you, NaN and how it spreads, and what to reach for when you are counting money.

TypeScript

Open a terminal and add two numbers a ten-year-old could handle:

typescript

console.log(0.1 + 0.2);      // 0.30000000000000004

Nothing is broken. This is not a fault in the language and not something you can configure away — it happens in nearly every programming language, for a reason worth ten minutes of your life. By the end of this lesson you will know why, when it matters, and what to reach for when you are counting money.

One type for every number

Most languages have several numeric types — whole numbers, decimals, small ones, large ones. Here there is one:

typescript

const count = 400;          // number
const price = 12.99;        // number
const negative = -7;        // number

That is simpler, and it means the decimal behaviour applies to everything. 400 and 400.0 are the same value, stored the same way.

The arithmetic operators:

typescript

10 + 3;      // 13
10 - 3;      // 7
10 * 3;      // 30
10 / 3;      // 3.3333333333333335
10 % 3;      // 1     the remainder
10 ** 3;     // 1000  ten to the power of three

Division always produces a decimal — 10 / 2 is 5, not a separate whole-number type, because there is no separate type. For a whole result, discard the rest deliberately:

typescript

Math.floor(10 / 3);    // 3    round down
Math.trunc(-10 / 3);   // -3   cut toward zero
Math.round(10 / 3);    // 3
Math.ceil(10 / 3);     // 4    round up

Math.floor and Math.trunc differ on negatives — floor rounds down to -4, trunc cuts toward zero to -3. Choosing the wrong one produces an answer that is off by one, but only sometimes.

% is the remainder, and it answers two questions that come up constantly:

typescript

seconds % 60;              // what is left over
count % 2 === 0;           // is it even
index % 100 === 0;         // every hundredth time round a loop

Why 0.1 is not 0.1

Here is the reason, and it is not about computers being unreliable.

Write one third as a decimal. You get 0.333333…, forever. It cannot be written exactly in base ten with a finite number of digits. Nobody finds that alarming — it is a fact about the notation, not about the number.

Computers store numbers in base two, and in base two the number that cannot be written exactly is one tenth. So 0.1 is stored as the closest value that fits, which is very slightly off:

text

you write     0.1
stored as     0.1000000000000000055511151231257827021181583404541015625

Add two of those slightly-wrong values and the error becomes visible:

typescript

0.1 + 0.2 === 0.3;      // false

The lesson is not "numbers are broken". It is that a number is an approximation of a decimal value, accurate to about seventeen significant digits, and asking whether two of them are exactly equal is asking a question the type cannot answer.

Comparing two decimals

Since exact equality is the wrong question, ask a better one: is the difference small enough not to matter?

Bad — comparing two decimals for exact equality.

Good — asking whether they are close enough.

The first version leaves the invoice unpaid and leaves no trace of why. There is no error and no warning — the customer paid the right amount, the comparison said false, and the only symptom is a support ticket next week.

Number.EPSILON is the smallest meaningful difference between two numbers near 1. For larger values, scale the tolerance to the size of the numbers involved, or — better — avoid the comparison entirely, which the next section is about.

Whole numbers are exact, so === on them is fine. The problem is decimals specifically.

Money needs different handling

Everything above leads here. Never store money in a number.

Money has exact decimal values. A price is 19.99, not approximately 19.99, and a total that is out by a hundredth of a penny per transaction becomes a real discrepancy across a hundred thousand of them — the kind that appears in an audit and takes a week to trace.

That second line is the dangerous part. Formatting hides the error on screen while it stays in the stored value, so the display reassures you and the database does not.

The straightforward fix is to work in the smallest unit — pence or cents — as whole numbers:

Whole numbers are exact up to about 9 quadrillion, so the arithmetic cannot drift. Divide only when displaying.

For larger amounts or more complex arithmetic, a decimal library (decimal.js, dinero.js) stores digits exactly. The principle is the same: keep money out of decimal number arithmetic.

The values that are not numbers

Two special values live inside the number type, and both catch people.

NaN means "not a number", and it is what you get from arithmetic that has no meaningful answer. Its defining property is that it spreads:

One conversion fails
Number("abc") gives NaN rather than raising. The form field was empty, or had a stray letter in it.
Every later calculation inherits it
NaN * quantity is NaN. NaN * 1.2 is NaN. It travels through your whole pipeline unchanged.
It lands somewhere real
A NaN in a database column, or the literal text "NaN" on a customer's screen. The bug report names the screen, not the conversion.

Nothing throws at any point, which is what makes NaN expensive

And the trap that makes it hard to detect:

So checking for it needs a purpose-built test:

Use Number.isNaN, not the older global isNaN, which converts its argument first and therefore reports true for "hello" before it has established anything useful.

Turning text into numbers

Values from forms and files arrive as text, and converting is where they go wrong.

Two of those lines are the ones that reach production.

Number("") is 0

A blank field becomes a quantity.

A customer who left the box empty gets zero rather than an error, and the order goes through.

parseInt("12abc") is 12

It stops at the first letter.

Occasionally that is what you want — reading "20px" — and usually it means malformed input was accepted silently.

Both accept input a person would call invalid, and neither says anything

Prefer Number() plus a Number.isFinite check, so a bad value is rejected rather than partly accepted.

For very large whole numbers beyond Number.MAX_SAFE_INTEGER (about 9 quadrillion), there is a separate type written with an n suffix:

You will rarely need it. Know it exists so that when a large identifier from another system loses its last digits, you recognise the cause.

Displaying numbers

toFixed returns a string, not a number, which means total.toFixed(2) + 5 joins text rather than adding.

Intl.NumberFormat handles thousands separators, currency symbols and the decimal conventions of different countries — a German reader expects 1.234,57 where a British one expects 1,234.57. Building that by hand gets it wrong for most of the world.

A cheat sheet to keep

Where to go next

You now know why decimals are approximate, when that matters and when it does not, and the rule that will save you a genuinely bad day: money does not go in a decimal number. You also know that NaN spreads without complaining, which is the most common way a wrong number reaches a database.

Next is Booleans, Conditions, and Truthiness, where programs stop running straight through and start choosing. It uses the comparisons introduced here, and adds the set of values this language treats as false — which includes 0 and NaN, and causes a specific bug worth meeting before you write it.

Before you move on, open a terminal and add 0.1 to itself ten times, then compare the result to 1. Then do the same with Number("") and watch an empty string become zero. Both take thirty seconds and fix the ideas permanently in a way that reading about them does not.