1.1.3 · D5Arithmetic & Number Systems
Question bank — Addition and subtraction — carrying, borrowing, word problems
Prerequisite ideas live in Place Value and Base-Ten System and the parent parent topic. Some traps point forward to Negative Numbers and Integers and Division Algorithm.
Figure s01 — carry climbs left. The addition is stacked ones-on-the-right. The two orange arrows show carry-outs travelling left into columns you have not evaluated yet. Read it right-to-left: the ones make (write , carry ), that climbs to become the tens' carry-in, and so on. This is the picture behind the "reading order" true/false and the "forgotten carry" error below — the loan physically moves before you touch the next column.
Figure s02 — borrow reaches left across zeros. The subtraction is stacked the same way. The magenta arrows show borrow-outs reaching left: the ones need to borrow, but their neighbour is , so that must itself borrow from its neighbour first — a chain. Each zero the chain passes turns into a (it borrows to become , lends to become ). This is the picture behind the "borrow across zero" error and the "" trap.
True or false — justify
A carry-out of a column can be if both digits are .
False. The most a column can hold is its two digits plus one carry-in: , and , so the carry-out it sends left is always or .
A carry-in to a column can be more than .
False. A carry-in is exactly the carry-out of the column to its right (figure s01), and that carry-out is capped at ; so no column ever receives more than a single .
Borrowing can be when the top digit is much smaller than the bottom.
False. You only ever need one borrow-out, worth exactly , since is at least , always any single digit .
Adding two 3-digit numbers can give a 4-digit answer.
True. The final hundreds column can carry once into a new thousands column, e.g. ; the leading is a carry into a fresh place.
Subtracting two 3-digit numbers can never give a 4-digit answer.
True. A difference is at most the minuend itself (when the subtrahend is ), so it can't grow past digits — subtraction only shrinks or keeps size.
and give the same answer as long as you ignore the sign.
False in general. The magnitudes match only because , but and are opposite numbers; treating them as equal is exactly the "big-minus-small per column" mistake in disguise (see Negative Numbers and Integers).
Carrying and borrowing create no new value — they only repackage it.
True. A carry trades ones for ten; a borrow trades ten for ones. The total value is untouched, only the column it sits in changes.
You can always check a subtraction by adding the difference to the subtrahend.
True. Because addition undoes subtraction, must return the minuend; if it doesn't, the subtraction is wrong.
Reading order (left to right) is the correct order to process a column addition.
False. Columns are processed right to left (ones first): in the ones give , sending a carry-out left into the tens before you evaluate them; look at figure s01 — the arrow climbs into a column you haven't touched yet, so starting from the left would strand the carry.
Spot the error
": ones give , so I write under the ones and get -ish."
Error: a column holds one digit only. Write , carry the into the tens; , so the extra ones are one ten, not a second ones digit.
", ones column: because is the bigger number."
Error: the minuend digit () must stay on top. You needed , which forces a borrow (), not the reversed . Reversing computes , a different problem.
": the ones is , nothing to borrow next door either since that's , so I'll just write ."
Error: a middle borrows from its neighbour first, becoming , lends (turning into ), and passes the chain along — trace the magenta arrows in figure s02. So : both zeros become .
": I lined the up under the instead of under the ."
Error: numbers must be right-aligned on the ones column (as stacked in figure s01). The lone is ones, so it belongs directly under the ; then (write , carry ) gives . Lining it under the secretly turns the into .
"I added a carry of but forgot it existed when I did the next column, and the answer came out too small there."
Error: the carry-out is a loan the previous column owes the next one (the orange arrows in figure s01); it must be added as a carry-in before you evaluate that column. Skipping it undercounts that place by exactly times its worth.
" minus one is still basically a thousand, I'll write ."
Error: borrowing chains through all three zeros — . Every zero passed becomes a (same chain as figure s02, one column longer); the thousands digit drops from to and disappears.
"To subtract I did , done."
Error (incomplete, not wrong direction): you rounded up to , so you subtracted too much. Add it back: . This is a fine estimation trick only if you correct the adjustment (see Estimation and Rounding).
": I right-aligned the last digits, lining under , and got ."
Error: with decimals you align on the decimal point, not the last digit. Writing under (pad with a zero) puts tenths under tenths: . Last-digit alignment mixes tenths with hundredths.
": I lined the of under the of and got -ish."
Error: the same decimal-alignment trap, now in subtraction. Pad to and align the points so tenths sit under tenths: . Last-digit alignment made you subtract hundredth from hundredths incorrectly.
"A problem says 'how many more books than pens', so I add books and pens."
Error: "how many more than" signals a difference, not a total. You subtract the smaller quantity from the larger; adding answers a different question (see Word Problem Translation).
Why questions
Why does a column overflow at exactly and not or ?
Because we use base ten: there are exactly ten symbols –, and the eleventh amount () is by definition one unit of the next place, so overflow starts the instant a column reaches .
Why is the carry always or in addition, but a carry in multiplication can be larger?
In addition each column sums at most , giving carry-out (floor round down); the orange arrows in figure s01 therefore never carry more than a single . Multiplication can produce column values into the eighties, so its carries range higher (see Multiplication as Repeated Addition).
Why does borrowing across a zero turn that zero into a ?
The zero has nothing to lend, so it first borrows from its own neighbour (becoming ), then lends down (becoming ). It is a borrower and a lender in the same instant — trace the two magenta arrows in figure s02, where each zero passed emerges as a .
Why must we add and subtract the same when borrowing, and how do we know it's exact?
We replace top digit with so subtraction is possible, then remove from the next column as a (a borrow-out). Since and cancel, the number's value is unchanged — it's just rewritten across columns.
Why can we verify any difference by turning it back into an addition?
Because subtraction is defined as the inverse of addition: is "the number that adds to to give ." So must return , making the reverse-add a genuine proof rather than a coincidence.
Why does from the Division Algorithm describe carrying?
Here (the quotient) counts whole tens inside the column sum and (the remainder, ) is what's left below ten. So is exactly the carry-out and is the digit written — carrying is division-by-ten applied to the base.
Why does word-problem order matter less for and chained together than you'd fear, yet subtraction alone is not associative?
Read left to right, each operator acts on the running total, so is unambiguous: . But subtraction on its own is not associative — while — which is why we fix the reading order instead of regrouping freely.
Edge cases
What is the sum's carry behaviour when one addend is , e.g. ?
The column simply writes with carry-out ; adding zero changes nothing, which is why is the identity for addition.
What happens to borrowing when the top digit already equals the bottom, e.g. ?
No borrow is needed: , the exact boundary between "borrow" and "no borrow." Only a strictly smaller top digit forces a borrow.
What if a subtraction column is with but a borrow-in of arrives, e.g. effectively ?
Now it's , so you must borrow: , and pass a borrow-out up. Equal digits are safe only when no incoming borrow tips them negative.
What does equal for any number, and why is that a clean edge case?
Always : subtracting a number from itself leaves nothing, since every column matches and cancels — the tidy boundary where the difference vanishes.
What does equal, and what does it reveal about zero?
It equals unchanged, showing is the "subtract-nothing" identity — every column keeps its digit, no borrow ever triggers.
When subtracting , what silent edge case bites, and how do you disarm it?
You must pad the shorter decimal so the points align: treat as , then subtract point-under-point to get . Aligning on the last digit instead mixes tenths with hundredths — the subtraction twin of the addition decimal trap.
When adding or , what is the silent edge case?
Missing decimal places must be padded with zeros so points line up: treat as and align the point, giving . Skipping the pad is the decimal-alignment trap in a milder disguise.
Can you ever need to subtract a bigger number from a smaller one in a real problem, and what then?
Yes — the honest answer is a negative number (a shortfall or debt), which base-ten column rules alone can't express; you step into Negative Numbers and Integers to handle it.
What is the largest single-column sum possible with a carry-in, and why does it cap the carry?
. Since , , proving the carry-out can never reach no matter the digits.
Connections
- Place Value and Base-Ten System — every trap here is really a place-value trap.
- Division Algorithm — carrying is ; borrowing is its reverse.
- Negative Numbers and Integers — where "top smaller than bottom" honestly leads.
- Estimation and Rounding — the round-then-correct traps.
- Word Problem Translation — the keyword-to-operation traps.
- Multiplication as Repeated Addition — where carries grow past .