You are working through a proof by contradiction. The algebra is flowing. Then, suddenly, you write down a line that cannot be true: 2 = 3, or k > k, or \gcd(p, q) = 1 alongside \gcd(p, q) \geq 2. Your first instinct is embarrassment — I must have made an error somewhere — and you go back to hunt for the mistake.

Stop. That uncomfortable line is not a bug. It is the goal of the entire method. You were trying to derive an impossibility. You just did. The proof is finished — do not debug it, celebrate it.

This article is about training the reflex. When the algebra hands you an obvious impossibility, your response should be "proof closed," not "what went wrong."

Why the instinct to debug is wrong

Through years of doing mathematics, you have been trained by thousands of direct computations. In those, deriving 2 = 3 really is a bug — you dropped a sign, misread a coefficient, divided by zero. Finding the bug and fixing it is the right move every time.

Contradiction inverts that training. Here, the goal is not a valid answer — it is an obvious impossibility. You assumed the negation of what you wanted to prove, precisely so that the algebra would produce something absurd. An absurd output is not a mistake; it is evidence that the assumption was wrong. That evidence is the proof.

Why the reflex has to be re-trained: the contradiction method takes a cognitive pattern you have used hundreds of times (debug impossible outputs) and flips it (celebrate impossible outputs). Without explicit practice, your default is to apply the old pattern, which makes you discard valid proofs as bugs. Students who do not re-train this reflex lose marks on exams by "fixing" proofs that were already complete.

What a wall looks like

Walls come in several common shapes. Each one is a legitimate endpoint of a contradiction proof:

All five shapes signal "proof complete, go flag it." The worst error is not recognising the shape and continuing to push the algebra forward.

The detection checklist

When a suspicious line appears, run this three-step check:

Step 1. Read the line. Is it false on its face? (2 = 3 is. n is even is not.)

Step 2. If it is not false on its face, pair it with every entry in your assumption box (see Keep a Running List of Assumed Facts). Does the pair form "X is true and X is false" for some X?

Step 3. If neither, pair it with your known-facts box. Does it deny a theorem?

If the answer is yes at any step, stop. Do not rewrite. Do not substitute values. Do not try to simplify further. Write the flag sentence and close the proof.

Why debugging a wall destroys the proof

If you do debug — if you go back and "fix" the step that produced 2 = 3 — two bad things happen.

First, you may actually introduce an error that was not there. The previous algebra was correct; the impossibility was its legitimate output. Fiddling with it can turn correct steps into incorrect ones.

Second, even if you stumble onto an algebraically consistent re-derivation, the new derivation has lost the wall. You now have a proof that produces a nothing-special result from the negation of the claim, which proves nothing. A contradiction proof that does not produce a contradiction is not a proof.

Both outcomes are worse than celebrating the wall you found.

The "debugging trap" in action

Claim. There is no integer n with n^2 \equiv 2 \pmod 4.

Proof attempt. Suppose, for contradiction, some integer n has n^2 \equiv 2 \pmod 4. Case 1: n is even, n = 2k. Then n^2 = 4k^2 \equiv 0 \pmod 4. But we assumed n^2 \equiv 2 \pmod 4, so 0 \equiv 2 \pmod 4.

Trap: "Wait, 0 \equiv 2 \pmod 4 is obviously false. Let me go back and re-check the case."

Correct response: 0 \equiv 2 \pmod 4 is false. That is the contradiction. Write:

"We have derived 0 \equiv 2 \pmod 4, which is false. Hence case 1 is impossible."

Then handle case 2 (n odd) similarly. Both cases hit walls. The claim follows. \blacksquare

If you had "debugged" the case by re-deriving n^2 from scratch, you would either produce the same wall again (wasting time) or introduce an error and lose the proof. The only move is: recognise the wall, flag it, close the case.

The emotional retrain

The reason this reflex is hard to internalise is emotional. An impossible result feels like failure — your brain was trained by years of direct algebra to experience 2 = 3 as a red flag. Proof by contradiction asks you to override that reflex and treat the red flag as green.

One trick that helps: as soon as you start a contradiction proof, announce to yourself "I am looking for an impossibility." Hold that framing throughout the derivation. Then when the impossibility arrives, you recognise it as the thing you were searching for, not as a bug.

A second trick: end every contradiction proof with a fixed three-sentence template:

  1. "We derived [X]."
  2. "This contradicts [Y] because [reason]."
  3. "Therefore the assumption [assumption] is false, and the original claim holds."

Writing this template triggers the celebration reflex. It also doubles as the proof's conclusion, so it is worth the muscle memory.

The training drill

Pick five famous contradiction proofs (\sqrt{2} irrational, infinitude of primes, no largest integer, the Cantor diagonal argument, the halting problem sketch). For each, identify the exact line that is the wall. Write down the two statements whose collision produced the wall. Do this on paper, by hand, five times.

After this drill, your pattern-matching for walls becomes reliable. When you encounter a wall in a new proof, your brain will recognise the shape in under a second.

One-line rule

In a proof by contradiction: the moment an impossible line appears, pause, celebrate, flag. Do not debug, do not re-derive, do not soften. The impossibility is what you came for. Claim your proof.

Related: Proof by Contradiction · When Is It Really a Contradiction (vs Just Something Weird)? · Do I Have to Flag the Contradiction Explicitly? · Keep a Running List of Assumed Facts · What If My Contradiction Is Just an Algebra Mistake?