You want to prove that n² + n is even for all integers n. A classmate argues that you must find an algebraic manipulation working uniformly for all n, and that splitting into even/odd cases is a 'weaker' approach. Which response best captures the methodological truth?
AThe classmate is correct — proof by cases is only valid when no general proof exists
BProof by cases is fully rigorous and often the clearest proof; the even/odd case split gives a complete proof with no need for a 'better' alternative
CProof by cases works here but should be used only as a last resort when algebraic methods fail
DProof by cases requires mutually exclusive cases, so even/odd is invalid since some integers might be both
Proof by cases is not a fallback — it is a legitimate and often the *cleanest* proof strategy available. The odd/even partition is exhaustive (every integer is one or the other) and mutually exclusive, making it perfectly valid. Option D is wrong: overlapping cases are permitted — only exhaustiveness is required. Option A reflects a common but false hierarchy where 'general' proofs are inherently superior.
Question 2 Multiple Choice
A student proves a statement 'for all integers n ≥ 0' using two cases: n is positive and n is negative. A reviewer says the proof has a critical gap. What is it?
AThe cases overlap — some integers are both positive and negative
BThe case n = 0 is omitted; zero is neither positive nor negative, so no case covers it
CProof by cases cannot be used for statements about integers — it only works for finite sets
DThere is no gap — if the proof works for positive and negative n, it works for all n ≥ 0
The partition {positive, negative} is not exhaustive over the domain {n ≥ 0} because n = 0 falls into neither case. This leaves a genuine gap: the conclusion has not been established for n = 0. A proof by cases is only complete when every element of the domain falls into at least one case. Forgetting edge cases like zero, or boundary values, is the most common error in case proofs.
Question 3 True / False
In a proof by cases, the cases should be mutually exclusive — no element of the domain can fall into more than one case.
TTrue
FFalse
Answer: False
Mutual exclusivity is not required. Only exhaustiveness is required: every element of the domain must fall into at least one case. Overlapping cases are perfectly valid — you simply prove the conclusion in each case, and since every instance is covered by at least one case, the proof is complete. The parity split (even/odd) happens to be both exhaustive and mutually exclusive, but the latter is a bonus, not a requirement.
Question 4 True / False
A proof by cases is considered a fully rigorous mathematical proof, not a shortcut or fallback method.
TTrue
FFalse
Answer: True
Proof by cases is a standard and rigorous proof technique, not a lesser substitute. It is often the *most* transparent proof available, especially in number theory and combinatorics, because it makes the reasoning in each sub-situation completely explicit. The mathematical community treats it as equal in rigor to direct proof, proof by contradiction, or any other method — provided the cases are exhaustive.
Question 5 Short Answer
Why must the set of cases in a proof by cases be exhaustive, and what exactly goes wrong if an edge case is omitted?
Think about your answer, then reveal below.
Model answer: The cases must be exhaustive because the proof only establishes the conclusion within each case it handles. If any instance falls outside all cases, the conclusion has simply not been proven for that instance — the proof has a gap. The final step of a case proof is: 'since every element of the domain falls into at least one case, and the conclusion holds in each case, it holds universally.' That step fails if even one element is unaccounted for. A proof that omits n = 0 while claiming to cover all non-negative integers is genuinely incomplete, not merely inelegant.
Exhaustiveness is what licenses the universal conclusion. Without it, you have proven the statement for some elements but not all. The common failure mode is forgetting boundary cases (zero, the empty set, a = b in 'a < b or a > b or a = b') — these are mathematically real instances that require explicit handling.