Questions: Arithmetic Operators and Operator Precedence

Question 1

What is the value of the expression `10 - 3 * 2 + 4`?

• A. 18 — evaluated left-to-right: 10−3=7, 7*2=14, 14+4=18
• B. 8 — multiplication first: 3*2=6, then left-to-right: 10−6+4=8
• C. 0 — subtraction and addition cancel out after multiplying
• D. 14 — the addition is evaluated before the subtraction due to left-to-right order

Answer: (B)

Operator precedence applies: multiplication (*) has higher precedence than subtraction (−) and addition (+), so 3*2=6 is evaluated first. Then the remaining operations are evaluated left-to-right at equal precedence: 10−6=4, 4+4=8. Option A is the classic left-to-right-ignoring-precedence error — the mistake of treating 2+3*4 as 20 instead of 14.

Question 2

A student writes `2 ** 3 ** 2` expecting the result `(2**3)**2 = 64`. What does the expression actually evaluate to?

• A. 64 — exponentiation is left-associative, so 2**3 is computed first, giving 8, then 8**2 = 64
• B. 512 — exponentiation is right-associative, so 3**2 = 9 is computed first, then 2**9 = 512
• C. 64 — when operators are repeated, the language always picks the leftmost operation
• D. 512 — the larger base is always evaluated first in chained exponentiation

Answer: (B)

Exponentiation is right-associative — the rightmost operation is evaluated first. `2 ** 3 ** 2` is parsed as `2 ** (3 ** 2)` = `2 ** 9` = 512. This is the important exception to the general left-to-right associativity of arithmetic operators. The student's expectation of 64 reflects applying left-associativity where right-associativity applies. To get 64, the student should write `(2 ** 3) ** 2` explicitly.

Question 3

The expression `17 % 5` evaluates to 2.

• T. True
• F. False

Answer: True

The modulo operator (%) returns the remainder after integer division. 17 ÷ 5 = 3 with remainder 2, so 17 % 5 = 2. Modulo is not a percentage operator — it computes the remainder. It's useful for checking divisibility (n % 2 == 0 tests if n is even), wrapping values around a range (e.g., hour % 12 for clock arithmetic), and cycling through indices.

Question 4

Adding parentheses to an expression in a way that reflects the order it would already be evaluated can change the result.

• T. True
• F. False

Answer: False

Parentheses override precedence by forcing a specific evaluation order, but if the parenthesized order matches what precedence already prescribes, the result is identical. `(3 * 4) + 2` and `3 * 4 + 2` both equal 14, because multiplication already has higher precedence than addition. Parentheses that reflect the existing evaluation order are purely for readability — they communicate intent without changing computation.

Question 5

Explain why operator precedence rules exist in programming languages, and what problem would arise if all operators were evaluated strictly left-to-right.

Model answer: Operator precedence ensures that mathematical expressions in code behave consistently with algebraic convention — multiplication and division bind more tightly than addition and subtraction, matching what students learn in mathematics. Without precedence rules, `2 + 3 * 4` would evaluate left-to-right as `(2 + 3) * 4 = 20` instead of the mathematically correct `2 + (3 * 4) = 14`. Programmers would then need explicit parentheses around every multiplication in a mixed expression, making arithmetic code verbose, error-prone, and inconsistent with mathematical notation. Precedence rules reduce visual noise while keeping expressions unambiguous.

This is an example of a language design decision that prioritizes ergonomics and mathematical consistency. The precedence hierarchy (PEMDAS/BODMAS) is essentially built into every programming language's parser. Knowing the rules lets you write `a + b * c / d` without parentheses when the default evaluation order is correct, and add parentheses only when you need to override it — which is the minimum-friction way to express arithmetic intent in code.