How this instrument works
Modulo sits at the same precedence level as multiplication and division, which places it above addition and subtraction in the standard order of operations. Written without parentheses, a + b mod c is parsed as a + (b mod c): the modulo applies only to b and c, and that smaller result is what gets added to a. Reaching (a + b) mod c instead requires parentheses that force the addition to happen first, before the whole sum gets reduced.
This is exactly the sort of rule that reads harmlessly until two people compute the same expression and land on two different numbers. For a=5, b=17, c=7, a + b mod c evaluates the modulo first — 17 mod 7 is 3 — then adds: 5 + 3 = 8. Writing the same three numbers as (a + b) mod c instead adds first — 5 + 17 is 22 — then reduces: 22 mod 7 is 1. Same inputs, same operators, one difference in placement, and the outputs are 8 and 1: genuinely different, not a rounding quirk.
It would be convenient if the two orders always agreed, but they do not, and the pairing above is the proof — 8 is not 1. Some particular number choices do land on the same result by coincidence: setting a to zero removes the discrepancy entirely, since adding zero never changes anything either way, and certain other combinations happen to reduce to equal values too. That agreement belongs to those specific numbers, not to the arithmetic in general, and it should never be mistaken for evidence that the parentheses stopped mattering.
- Enter the first number in a and the second in b.
- Enter the shared divisor in Modulus (c).
- Read a + (b mod c) for the result when modulo runs first, following standard precedence.
- Read (a + b) mod c for the result when parentheses force the addition to run first instead.
- Compare the two — a matching pair of values is a coincidence of those specific numbers, not a rule.
Worked example — 5, 17, and 7 diverge
Take a=5, b=17, c=7. Read without parentheses, a + b mod c evaluates the modulo first: 17 mod 7 is 3, because 7 goes into 17 twice with 3 left over, and adding that to a gives 5 + 3 = 8. Read instead as (a + b) mod c, the addition happens first: 5 + 17 = 22, and only then does the modulo apply: 22 mod 7 is 1, since 7 goes into 22 three times with 1 left over.
Both calculations use the exact same three numbers and the exact same two operators — only the placement of one pair of parentheses differs — yet one path lands on 8 and the other on 1. That gap is the entire lesson: modulo's precedence is not a formality, and dropping the parentheses changes which operation runs first and therefore changes the final answer.
Questions
Does modulo happen before or after addition?
Before, by default — modulo shares its precedence with multiplication and division, all evaluated before addition and subtraction unless parentheses say otherwise. Written as a + b mod c, only b mod c is computed first, and that smaller result gets added to a; the whole sum is never reduced unless parentheses explicitly wrap it, as in (a + b) mod c instead.
Why do a + (b mod c) and (a + b) mod c give different answers?
Because they are genuinely different calculations, not two ways of writing the same one. For a=5, b=17, c=7, the first evaluates 17 mod 7 = 3 and adds: 5 + 3 = 8. The second adds first, 5 + 17 = 22, and reduces once: 22 mod 7 = 1. A different order of operations produces a different final number — 8 against 1 — from identical starting inputs.
If two orderings happen to agree, do parentheses stop mattering?
No — agreement in one specific case is a coincidence of those particular numbers, not proof that placement stopped mattering. For a=0, b=10, c=3, both a + (b mod c) and (a + b) mod c equal 1, purely because adding zero never changes a value either before or after the modulo step. Change a to anything nonzero and the two expressions can diverge again, exactly as the 5, 17, 7 case shows.
How do I force addition to happen before the modulo?
Add explicit parentheses around the addition: (a + b) mod c. Parentheses always override default precedence, so wrapping a + b guarantees the sum gets computed in full before the modulo operator ever runs, regardless of how modulo's own precedence would otherwise have ordered the calculation.
Is this precedence rule the same across programming languages?
In most mainstream languages — including Python, JavaScript, C, and Java — the remainder operator sits at the same precedence level as multiplication and division, matching the convention used here. It is still worth checking a given language's own reference before relying on it, since precedence tables are a design choice made by each language rather than a universal law of arithmetic.