Problems with Subtraction

Subtraction is the operation of “taking away”, and acts like the “opposite” of addition. For example, we can use a subtraction to “undo” an addition:

x+yy=x plusxyy x

This is a fine idea, but unfortunately subtraction is not as well-behaved as addition, and I personally think it causes more problems than it solves.

Subtraction is redundant

We can define subtraction using addition and negation (using overbar notation for negatives):

xyx+y¯ xy plusxunary_minusy

Hence situations involving negatives don’t need subtraction: we can stick to additions, and sprinkle in some negatives as needed. Furthermore, if a situation doesn’t allow negatives, then it doesn’t allow subtraction either, since subtraction gives negative answers when the second value is larger than the first (e.g. 57=2¯ 57 unary_minus2).

So any time we might want subtraction, we could add negatives instead; and any time we can’t use negatives, we also can’t use subtraction. Thus subtraction isn’t needed. We might find it useful, but it’s ultimately just an abbreviation for adding negatives.

Adding negatives using negative digits

We can use the familiar “long addition” algorithm to add negatives, if we think of them as having negative digits!

Subtraction is hard

We’ve seen that subtraction is the same as adding negatives, but that doesn’t tell us whether one is “better” than the other. Now I’ll show that adding is preferable, since it follows many nice rules/patterns that subtraction doesn’t; hence making it easier to add negatives (both mentally, and on a computer)!

Subtraction doesn’t commute

We can swap around the values of an addition without changing the result: we say addition commutes, i.e. that x+y=y+x plusxyplusyx.

In contrast, we can’t swap around the values of a subtraction, since xyyx xy yx . In fact, doing so will negate the result: xy=yx¯ xy unary_minus yx (we say that subtraction “anti-commutes”).

Subtraction doesn’t associate

Addition extends to arbitrarily-many inputs, which we call being “associative”. In particular, ( x + y ) + z is the same as x + ( y + z ) , so we can just avoid nesting altogether and write x+y+zplusxyz (the same goes when dealing with more than three inputs, nested in any way).

In contrast, using subtraction with more than two values is ambiguous. For example 1 - 2 - 3 could mean (12)3=1¯3=4¯ 12 3 unary_minus13 unary_minus4 or it could mean 1(23)=11¯=2 1 23 1unary_minus1 2, which give different results. In general (xy)zx(yz) xy z x yz , so we’re forced to keep careful track of nesting when using subtraction.

Associative operations are also better for computers, since they’re trivial to calculate in parallel. For example, if we have three processors, we can calculate a+b+c+d+e+fplusabcdef in parallel by transforming it into (a+b) + (c+d) + (e+f) ; the result will always be identical, but the nested parts can be calculated independently, and hence on separate processors at the same time. We cannot perform such transformations for operations that aren’t associative; hence subtraction can’t easily be done in parallel.