Arithmetic and Pre-Algebra for ML

Addition, subtraction, multiplication and division are what every loss, metric and data split is built from. Get fluent here and the rest of ML math stops feeling slippery.

Six response times on a number line add to 108, and dividing by 6 lands the mean at 18, the same add-then-divide pattern every ML metric repeats

Why Does This Exist?

Every number in ML is arithmetic wearing a costume. A training loss is a mean. Accuracy is a fraction scaled to 100. A data split is a ratio. A learning-rate schedule is multiplication repeated until it matters. None of these need calculus to check, and checking them is how you catch the bugs that waste GPU days: the split that is not 80/20, the accuracy that counts the wrong class, the loss that averages over padding tokens.

This page covers the four operations, how order changes answers, and the humble mean. The complete precedence rules get their own page in order of operations. Once these feel automatic, the next step is summarising whole datasets, which is the job of descriptive statistics.

The one idea you need first. Picture a number line: every number is a position, adding moves right, subtracting moves left, and multiplying by 2 stretches every distance from zero to double. Hold that picture and the rest is bookkeeping.

Think of It Like This

A cash register receipt

A receipt is arithmetic with evidence. Each line multiplies price by quantity, the subtotal adds the lines, tax multiplies the subtotal by a rate, and the total adds that on. Every step leaves a number you can point at.

ML metrics are receipts without the paper. A mean adds six response times and divides once. Accuracy counts correct predictions and divides by the total. When a metric looks wrong, you do what you do with a suspicious receipt: recompute one line at a time until a line disagrees. Nobody audits a receipt by staring at the total.

Where it stops: a receipt never divides by zero items, and it never averages Monday's average with Tuesday's average. Both moves break the analogy, and both get their own warnings below.

How It Actually Works

Four operations, each with a plain meaning. Adding combines counts. Subtracting finds the gap between two counts. Multiplying is repeated adding: $3 \times 4$ is three groups of four. Dividing splits into equal groups, or equivalently asks how many groups fit: $12 / 4 = 3$ because three fours make twelve. Division by zero has no answer. It is not zero and not infinity. It is undefined, and every NaN that ever killed a training run started life as someone dividing by something that could be zero.

Order changes answers

Operations do not run left to right. Multiplication and division run before addition and subtraction, so $3 + 4 \times 2 = 11$ , not 14. Parentheses override everything: $(3 + 4) \times 2 = 14$ . Exponents come before multiplication, which is why $2 + 3 \times 4^2 = 50$ and not 400. The full rules, with the cases code gets wrong, live in order of operations.

Worked example: a mean from six numbers

Six response times in milliseconds: $4, 8, 15, 16, 23, 42$ .

Step 1, add: $4 + 8 = 12$ , then $12 + 15 = 27$ , then $27 + 16 = 43$ , then $43 + 23 = 66$ , then $66 + 42 = 108$ . The total is $108$ .

Step 2, divide by the count: $108 / 6 = 18$ . The mean is $18$ ms.

That is the whole pattern behind mean squared error, accuracy and every averaged metric you will meet: add everything up, divide by how many there were. The diagram above shows these six values on a number line with the mean marked where the pile would balance.

Code

1times: list[float] = [4, 8, 15, 16, 23, 42]2
3total: float = sum(times)4mean: float = total / len(times)5print(total)  # -> 1086print(mean)   # -> 18.0

Two lines, and they are the template for every metric: accumulate, then divide by the count. Note len(times) in the denominator instead of a hardcoded 6, so a seventh measurement cannot silently skew the result.

Watch Out For

Averaging averages from different-sized groups

Two batches score 90% and 50%. The average of the two percentages is 70%, and it is wrong unless the batches are equal. If the first batch held 900 examples and the second held 100, the true accuracy is $(810 + 50) / 1000 = 86\%$ .

The symptom is a metric that disagrees with a recount. The fix is to go back to counts: sum the raw correct predictions, sum the raw totals, divide once. Never average a rate with another rate unless the denominators match.

Dividing by something that can be zero

Precision divides by the number of predicted positives. Early in training a model can predict zero positives, and $5 / 0$ is not zero accuracy, it is undefined. NumPy answers inf with a warning, plain Python raises, and a training loop that logs the value keeps going with poison in its history.

Guard the denominator: total / len(times) if times else 0.0. Decide the empty case on purpose instead of letting the hardware decide it for you.

The Quick Version

Adding combines, subtracting finds gaps, multiplying repeats addition, dividing splits into equal groups.
Multiplication and division run before addition and subtraction; parentheses override everything.
A mean is add-then-divide, the template behind MSE, accuracy and every averaged metric.
Division by zero is undefined, not zero, and it is the ancestor of many training NaNs.
Average counts, never rates: recompute from raw totals when group sizes differ.