[7.8] Error identification & correction

[7.8] Error identification & correction in algorithms

Programmers make mistakes. At IGCSE you must be able to spot errors in algorithms written in CAIE pseudocode or a high-level language such as Python, and then propose clear corrections. This skill blends careful reading with logical thinking: you check initial values, test conditions, loop bounds, data types, and the order of steps. You also need to justify why a change fixes the problem, not just guess. This page explains common error types, shows how to diagnose them, and provides corrected versions you can learn from.

Categories of errors you should recognise

Error category What it looks like Typical symptom Fixing approach
Logic error Wrong condition, misplaced statement, incorrect operator Program runs but gives wrong result (e.g. average too small) Trace with sample data; correct condition/operator or reorder steps
Runtime error Division by zero, out-of-range index, infinite loop Program crashes or never finishes Add checks, adjust bounds, ensure loop termination
Boundary/off-by-one Loop goes one time too few/many; inclusive vs exclusive mistake Misses first/last item; fails on smallest/largest values Review loop limits and comparison operators
Initialisation error Accumulator or flag starts with the wrong value First value ignored or extremes computed incorrectly Initialise using the first data item or a safe neutral value
Data type/format error Using INTEGER where REAL needed; concatenating instead of adding Truncated averages, string-like behaviour instead of arithmetic Choose correct data type and conversions

A practical approach to finding and fixing errors

  1. Read the specification carefully: what should the algorithm produce for specific inputs.
  2. Trace the algorithm using a small set of normal, boundary, and abnormal values, recording variable changes in a table.
  3. Compare the expected result with the traced result to locate the step where behaviour diverges.
  4. Propose a minimal correction and justify why it works for all cases, not only your test.
  5. Retest to confirm the fix does not introduce a new problem.

Worked patterns with common faults

Each tab shows a frequent mistake, a corrected version, and an explanation. Study the pattern, then practise on fresh examples.

Fault: loop misses the last element

The inner details of a counted loop matter. If the loop stops at length - 1 but the body accesses i + 1, you can miss pairs or cause an out-of-range access. Likewise, a loop intended to visit every item might stop one too early.

// CAIE Pseudocode (faulty)
// Sum all values in list data
DECLARE total : INTEGER ← 0
DECLARE i : INTEGER
FOR i ← 0 TO LENGTH(data) - 2   // stops too early; last item never added
  total ← total + data[i]
NEXT i
OUTPUT total
// Corrected idea
FOR i ← 0 TO LENGTH(data) - 1   // visit every index
  total ← total + data[i]
NEXT i

Why it fails: the original loop condition excluded the last index. Fix: change the upper bound to LENGTH(data) - 1, which is the last valid index.

Fault: WHILE loop never changes the condition

A WHILE loop must eventually make its condition false. Forgetting to update the counter or using the wrong update step can create an infinite loop.

// CAIE Pseudocode (faulty)
DECLARE n : INTEGER ← 5
WHILE n > 0 DO
  OUTPUT n
  // missing: n changes
ENDWHILE
// Corrected idea
WHILE n > 0 DO
  OUTPUT n
  n ← n - 1
ENDWHILE

Fix: update n inside the loop so the condition n > 0 will eventually be false.

Fault: using the wrong comparison at a boundary

Comparisons decide whether a value passes a rule. Using > instead of >=, or < instead of <=, can wrongly reject or accept boundary values.

// CAIE Pseudocode (faulty)
// Pass if mark is 50 or more
IF mark > 50 THEN
  OUTPUT "Pass"
ELSE
  OUTPUT "Fail"
ENDIF
// Corrected idea
IF mark >= 50 THEN
  OUTPUT "Pass"
ELSE
  OUTPUT "Fail"
ENDIF

Fix: include the boundary value by using >=. Always test with boundary data (e.g. 49, 50, 51) to confirm.

Systematic tracing: how to prove your correction

After a proposed fix, complete a small trace table with normal and boundary inputs. Record initial values, each loop pass, and outputs. If your correction is sound, the trace will match the requirements for all tested inputs, including edge cases.

Deep Dive: Flags and early exit

Flags are BOOLEAN variables such as found or swapped that record whether a condition has occurred. They help prevent infinite loops and reduce work. For example, a linear search can break as soon as the target is found, and bubble sort can stop when an entire pass makes no swaps. Errors often arise when flags are not initialised correctly or are never updated inside the loop.

Key terminology

  • Off-by-one error: a boundary mistake that processes one item too few or too many.
  • Initialisation: choosing starting values for variables (e.g. total ← 0, found ← FALSE).
  • Guard condition: a loop or selection condition that prevents unsafe actions (e.g. divide only if count ≠ 0).
  • Trace table: a step-by-step record of variable values used to follow an algorithm manually.
  • Logic error: a mistake in the algorithm’s reasoning that produces the wrong output without crashing.

 Key Takeaways

  • Identify error type first (logic, runtime, boundary, initialisation) to focus your correction.
  • Use small, well-chosen test values (especially boundaries) and trace tables to pinpoint where behaviour goes wrong.
  • Correct loop bounds and update steps to avoid off-by-one and infinite loop errors.
  • Initialise accumulators and flags sensibly, often using the first data item or a safe neutral value.
  • Justify corrections by explaining why they work and then retesting with normal and boundary data.