100 topics · Read, check sources and follow your curiosity.

A little room to wonder

Algorithms & Debugging

An algorithm gives a precise process for a task. Debugging compares its actual steps with its intended result, including cases that are easy to overlook.

How can a process work for familiar examples and still contain a mistake?

An IBM punched-card sorter has a row of output compartments for sorted cards.
A historical punched-card sorter makes a process tangible: a machine follows a defined sorting method rather than deciding what “organised” ought to mean. The photograph does not reveal its full algorithm.waelder · Source · CC BY 2.5

Specify the task before the instructions

An algorithm needs a defined starting situation and a result it is meant to produce. “Sort these cards from smallest to largest” is clearer than “organise the cards”. The allowed inputs matter: can numbers be negative, can a list be empty, and can values repeat?

Sequence sets the order of steps. A condition selects between alternatives, and a loop repeats a process. These structures can be expressed in ordinary words, drawings or code. Precision matters more than making an instruction look technical.

Trace the state, not just the final answer

A trace records how stored values change after each step. If you only inspect the final result, two different mistakes may accidentally cancel each other out. A step-by-step record helps locate where a process first differs from its intended behaviour.

A bug is not evidence that the learner is bad at computing. It is a mismatch to investigate. Useful debugging changes one suspected cause, reruns a relevant case and explains why the new version should handle that case.

Worked example: the largest-number bug

A fictional algorithm says: “Set largest to 0. Read each list item. If it is greater than largest, replace largest. Return largest.” For the list 4, 1, 9, the trace becomes 0 → 4 → 4 → 9, which looks successful.

Try −7, −2, −9. None is greater than 0, so the result stays 0 even though 0 is not in the list. Repair the starting rule: if the list is not empty, initialise largest to the first item and compare the remaining items. The trace is now −7 → −2 → −2, so the returned value is −2. The repair addresses the unsupported assumption that every largest value is non-negative.

One successful test is not a proof

The repaired process still needs an empty-list rule: return “no value” rather than reading an item that does not exist. Further useful cases include one item, repeated largest values and an already ordered list. Each case probes a different part of the specification.

Do not patch only the particular negative numbers in the example. A general repair explains the whole class of failure. In the same way, a robot instruction should define which way it faces before “turn left” is meaningful. You can test all these ideas on paper without installing software or entering personal data.

Only if you feel like trying

Build a small test set

  1. Trace the repaired largest-number algorithm for 5; for 3, 3, 1; and for an empty list.
  2. Record the expected result before following the steps.
  3. Write one additional input that tests a different boundary, then explain what it checks.

Optional. Work on paper, point to the example or talk it through. No account, purchase or public sharing is needed.