Numbers and arithmetic

Many languages make you choose: whole numbers go in one kind of box, numbers with a decimal point go in another, and big numbers go in a third. JavaScript does not. Every ordinary number — 3, -0.5, 1000000 — is stored in exactly the same format, a 64-bit double-precision floating-point value defined by a standard called IEEE 754.

That is a genuine simplification for you: 3 and 3.0 are the same value, and dividing two whole numbers can give you a fraction without any ceremony. It also has one consequence that surprises everybody, which the rest of this lesson is mostly about.

There is a second numeric type for very large whole numbers, called BigInt, written with an n on the end. You will not need it in this course and it is mentioned only so the word is not a mystery when you meet it.

Addition is +, subtraction is -, multiplication is * and division is /. Two more are less familiar. The remainder operator % gives what is left over after a division: 7 % 3 is 1, because three goes into seven twice with one left over. The exponentiation operator ** raises to a power: 2 ** 10 is 1024.

Remainder is the workhorse of anything cyclical — every second item, every third row, the hours on a clock — because a remainder can only ever be one of a small fixed set of answers. Note that it takes its sign from the left-hand value, so -7 % 3 is -1, not 2. That is why it is called remainder and not modulo; the two behave differently for negative numbers, and JavaScript has the first one.

JavaScript follows the arithmetic precedence you were taught at school: ** first, then * / %, then + -, and operators of equal rank are worked out left to right. So 2 + 3 * 4 is 14, not 20.

Round brackets override all of it, and they cost nothing. Professional code is full of brackets that a precedence table says are unnecessary, because a reader should not have to consult a table. If you had to think about it for more than a second, add the brackets.

Write one third as a decimal and you get 0.3333... forever. Stop anywhere and you have written down something slightly wrong. That is not a flaw in you or in decimals; it is that some fractions cannot be written exactly in base ten with a finite number of digits.

Computers store numbers in base two, and in base two it is 0.1 that cannot be written exactly. So the value stored when you write 0.1 is very slightly off, the same for 0.2, and when you add the two the small errors survive into the answer. 0.1 + 0.2 gives 0.30000000000000004.

Every mainstream language does this — Python, Java, C#, Excel — because they all use the same IEEE 754 format. It is not a JavaScript quirk, it is arithmetic on a finite machine.

Two practical rules follow. First, never compare two calculated fractional numbers with ===; compare whether the difference between them is smaller than a tolerance you choose. Second, for money, do not store 19.99 at all — store 1999 whole pennies, do all your arithmetic in whole numbers, and divide by 100 only when you display it.

The usual way to show a number to two decimal places is toFixed(2), and it is the right tool for that job. But read its result carefully: (2.5).toFixed(2) produces the TEXT 2.50, not the number 2.5.

That matters because text and numbers behave differently the moment you do anything else with them — a subject with a whole lesson of its own at the end of this module. Use toFixed at the very last moment, when the value is on its way to a screen, and never in the middle of a calculation.

Ask for something impossible and JavaScript does not stop the program. It produces a special value instead and carries on. Dividing by zero gives Infinity. Asking for a number from something that is not one — 0 divided by 0, or the square root of -1 — gives NaN, short for Not a Number.

NaN has a property no other value has: it is not equal to itself. NaN === NaN is false. That is deliberate, and it means the way to test for it is Number.isNaN(value), never value === NaN, which is false for absolutely everything.

NaN is contagious. Any arithmetic involving it produces NaN, so a single bad value early on can turn a whole page of results into nonsense with no error message anywhere. When a calculation gives you NaN, the bug is upstream of where you noticed it.

One quirk of this player: it prints values by converting them the way JSON does, and JSON cannot write NaN or Infinity, so printing them bare would show null. The example below wraps them in String(...) to see their real names. That is a limitation of this window onto the program, not of the values themselves.

All ordinary numbers share one floating-point format, so fractions are approximate: compare with a tolerance and keep money in whole pennies. % is remainder and takes the sign of its left operand; ** is a power. toFixed returns text. Impossible arithmetic yields Infinity or NaN, and NaN is detected with Number.isNaN because it is not equal to itself.