PEMDAS (another rant)

It’s been a while since I’ve complained about PEMDAS, so now’s a good time.

We make a big deal about pointing out that multiplication is commutative, and that addition is commutative, meaning that it doesn’t matter what order we perform either one in.

For instance, 4 + 3 + 5 = (4 + 3) + 5 = 4 + (3 + 5) = (4 + 5) + 3. Addition involves a collection of numeric values, and we can add those elements in any order: +[3, 4, 5] has a unique value regardless of the order.

Likewise, multiplication involves combining a collection of numeric values in whatever order we please: *[3, 4, 5] = 60, just as +[3, 4, 5] = 12. No matter what order we write it in, no matter what order we perform the calculations in.

So when we get to PEMDAS, we insist that we need to go “from left to right”. Why?

It’s clearly not because of multiplication and addition. It’s because of division and subtraction, and more crucially, it’s because of our notation. Our notation makes it look like division and subtraction are significantly different operations than their counterparts.

They are not. Division is the inverse of multiplication. Subtraction is the inverse of addition. Once we have introduced fractions and negative numbers, respectively, we don’t need division or subtraction at all.

I repeat: We do not need division or subtraction. AT ALL.

We could have a different system of notation where we have two binary operators (addition and multiplication) and two unary operators (negation and reciprocation). We could accomplish all the same mathematics, and we would no longer need the concept of going from left to right.

Seem weird? Seem outlandish? Seem like far beyond what any mathematician would do?

There’s a very powerful software package called Mathematica, which can do high level mathematics and beyond, that that’s exactly what it does.

In Mathematica, the command for seeing what operations it’s performing is ExpressionTree. To prevent it from evaluating first, we use the command Unevaluated. Here is how the Great and Powerful Mathematica is working behind the curtain:

In other words, it calculates 4/3 – 5 as 4 * 3^(-1) + -5. No division, no subtraction.

Mathematica is restricted by the fact that we don’t have a standard reciprocation function, although Stephen Wolfram could have come up with one. Let’s do that now: Let ÷n = 1/n = n^(-1).

So let’s get rid of the binary operators of subtraction and division, and replace them with the unary operators of negation and reciprocation. As a result, we no longer have to talk about “left-to-right” with the order of operations.

For instance, 2 – 7/5 + 6 * 5/2 = 2 + -7 * ÷5 + 6 * 5 * ÷2. Order within operations does not matter; do multiplication, then addition. Any order you please, as long as you don’t cross the addition walls.

Let’s go one step further and write this as collections. First we collect under multiplication: 2 + *[-7, ÷5] + *[6, 5, ÷2]. Then we collect under addition: +[2, *[-7, ÷5], *[6, 5, ÷2]].

This is effectively what Mathematica does, except it limits itself to binary operators, hence the expression tree can only have two branches at each node:

Now, I’m not suggesting that we get rid of our current notation and replace it completely with the collection notation. (Or… maybe we should?)

I’m not even suggesting that we get rid of binary subtraction and division entirely. (Yes, actually, I am, but don’t tell anyone.)

What I’m saying is that the ordering rules of mathematics, particularly PEMDAS, would be greatly streamlined if we understood that we could do this. That, in fact, Mathematica does do this already.

And, more crucially to the point of my rant: We only need to worry about “left-to-right”, which PEMDAS crucially relies on, because of our notation for division and subtraction. We could just switch notation and get rid of that.

Now: What about nested exponents? This DOES require a specific order, and it’s not left-to-right.

The first part of this is because exponentiation, unlike addition and multiplication, is not commutative. 2^5 does not equal 5^2, and so ^[2, 5] isn’t a valid concept. ^ is a binary operator where order matters; + and * are binary operators where order doesn’t matter (with real, and even complex, numbers; order for these can matter with different mathematical objects).

So how do we interpret 5^3^2? This is a matter of convention, since whichever one we choose, we can specify the other one with grouping symbols. For complete clarity, we could use grouping symbols regardless: 5^(3^2) = 1953125 is right-to-left, (5^3)^2 = 15625 is left-to-right.

Mathematicians chose 5^3^2 = 5^(3^2). The reasons for this are not entirely arbitrary; one is that because (5^3)^2 = 5^(3*2), it can more easily be rewritten without the parentheses (5^(3*2) does not need parentheses if we’re using superscripts). However, nested exponents are rare enough that it may be easier just to remember that “right-to-left” rule.

Indeed, a practical byproduct of mathematicians choosing that convention is that left-to-right, which is more common in the mathematics that high school students encounter, requires parentheses, meaning that the direction rule is even less commonly applied.

We could write exponentiation as an ordered set: ^(5, 3, 2), where we evaluate pairs from the right. But I think that even when using my collection notation, it’s better to keep exponentiation as ordered tuples: 5^3^2 = 5^(3^2) = ^(5, ^(3, 2)) and (5^3)^2 = ^(^(5, 3), 2).

What about radicals? All radicals can be rewritten as exponents, but even without that, the grouping symbol is built in; we even include it now even when it’s not needed. Historically, √ only took the overline (vinculum) when the argument contained multiple terms; now we always write it. Even so, though, ∜32 = 32^(1/4) = ^(32, ÷4).

What about logarithms? Here we do have a choice: We could write logs as ordered tuples parallel to exponents, so that log_4 16 = v(4, 16). Or we could use a unary operator and a universal base (either ten or the natural number e are obvious choices): log_4 16 = *[V16, ÷V4] (where v represents the binary operator and V represents the unary operator).

The choice between these would depend, I think, on whether a given calculation environment is mostly functioning within a specific base (ten or e), or whether any base might occur. At any rate, the Change of Base formula would become v(a, b) = *(Va, ÷Vb), strange looking at first but, I think, more natural in the long run.

So what does PEMDAS become?

Using the collection notation (which is a variation on Polish Notation, developed in 1924 by Jan Łukasiewicz), we don’t even need it for real number operations. Addition and multiplication are unordered collections; subtraction and division are unary; exponentiation is ordered tuples. Radicals are done away with; logarithms are either unary or binary (ordered tuples), depending on context and taste.

Using traditional notation but replacing a – b and a / b with a + -b and a * ÷b, respectively, means we only need parentheses with nested exponents or when we’re violating the standard “exponent stuff first, then multiplication, then addition”.

Also note that PEMDAS not only excludes radicals and logarithms (PLERMDAS, anyone), but it’s not even clear where trigonometric functions sit. How should we interpret sin x + 4? sin 4 * x? But that’s a rant for another time.

Anyway, elsewhere in the world, they use GEMA, which I do think is a superior acronym. It reinforces that we’re talking about exactly three levels of operators, and that grouping symbols (mostly parentheses and vincula) allow us to violate that order.

And if we must keep the current standard notation, I think it does improve understanding a lot to consider that – and ÷ are “married” to the term immediately to their right for the purposes of calculation order and reordering.