PEMDAS

PEMDAS stands for Parentheses, Exponents, Multiplication and Division, Addition and Subtraction. It's the mnemonic used in the United States for the order in which arithmetic operations are applied.

The rule

Evaluate expressions in this order:

1. Parentheses (or brackets): Anything inside grouping symbols is computed first, working from the innermost group outward.
2. Exponents: Powers and roots.
3. Multiplication and Division: Resolve them left-to-right when they appear together.
4. Addition and Subtraction. Also left-to-right.

The pairing of multiplication with division (and addition with subtraction) is the most commonly misread part. PEMDAS is four tiers, not six. "M" and "D" are at the same level, and 8 / 2 × 4 resolves to 16, not 1. Likewise 10 - 3 + 2 is 9, not 5.

Why the pairing matters

A worked example shows the failure mode. Consider 12 ÷ 4 × 3.

• Left-to-right at the same precedence tier: 12 ÷ 4 = 3, then 3 × 3 = 9. Answer: 9.
• Treating "M before D" literally: 4 × 3 = 12, then 12 ÷ 12 = 1. Answer: 1.

The second reading is wrong under the convention but gets defended often enough on social media to spawn a recurring genre of viral arithmetic disputes. The convention is unambiguous — multiplication and division share a tier and resolve left-to-right — but the mnemonic obscures that detail by putting the letters in sequence.

The same issue applies to subtraction: 10 - 3 + 2 evaluates as (10 - 3) + 2 = 9, not 10 - (3 + 2) = 5. Subtraction is not associative, so the left-to-right rule is doing real work here.

Implicit multiplication

Mathematical notation often elides the multiplication symbol. 2(3 + 1) and 2 × (3 + 1) denote the same value. Most conventions treat the elided form at the same precedence as explicit multiplication, but some communities (notably some physics textbooks and graphing-calculator manuals) bind implicit multiplication tighter than explicit. Under that variant 6 ÷ 2(1 + 2) evaluates as 6 ÷ (2 × 3) = 1 rather than (6 ÷ 2) × 3 = 9.

The viral arguments usually trace back to this ambiguity rather than to PEMDAS itself. The honest answer is that the expression is poorly written: an author who wants the tighter binding should use brackets to make it explicit.

PEMDAS in code

Programming languages carry their own precedence tables, and most align with PEMDAS for the arithmetic operators while adding tiers for comparison, logical, bitwise, and assignment operators. C, Java, Python, JavaScript, and Rust all evaluate 2 + 3 * 4 as 14, and all evaluate 2 ** 3 ** 2 (or 2 ^ 3 ^ 2 in some languages) as 2 ** (3 ** 2) = 512 rather than (2 ** 3) ** 2 = 64. The right-associative behaviour of exponentiation matches the mathematical convention.

Where languages disagree with PEMDAS is at the edges. Python and Haskell allow chained comparisons (a < b < c reads as a < b and b < c); C does not. Bitwise operators in C sit below arithmetic but above comparison, which is the source of a recurring class of bugs in expressions like flags & MASK == VALUE — the == binds tighter than the &, so the expression is silently flags & (MASK == VALUE). Defensive style guides recommend parenthesising aggressively whenever bitwise and comparison operators meet.

The lesson generalises: a precedence table you do not actively remember is a precedence table you should bypass with brackets. The cost of an extra pair of parens is one character of source; the cost of a precedence bug is the time it takes to discover the wrong answer is wrong.

Where the rule fails as a teaching tool

PEMDAS is concise enough to memorise but compact enough to mislead. Three failure modes recur:

• Treating it as six tiers instead of four. The "M then D" sequence in the acronym implies a precedence relationship that the convention does not actually carry.
• Forgetting left-to-right at equal precedence. Students who memorise the acronym without the associativity rule produce wrong answers on otherwise routine expressions.
• Treating implicit multiplication as definitionally tighter. Some teachers teach the variant; others teach standard PEMDAS. The student then meets an expression in the wild where the convention is unclear and the underlying author's intent is lost.

The mathematical community's response, more or less, is "use parentheses." Notation that depends on a memorised precedence table to disambiguate is fragile communication; notation with explicit grouping is robust. The same advice applies to code, to LaTeX, to spreadsheet formulas, and to any prose context where an arithmetic expression appears without typesetting that makes the structure visible.