Use pseudocode to write: a 'post-condition' loop

Topic 11.2 – Constructs: Post‑condition Loop (REPEAT … UNTIL)

Learning objectives

• Write correct Cambridge‑style pseudocode for a post‑condition loop using the REPEAT … UNTIL construct.
• Analyse a problem to decide when a post‑condition loop is the most appropriate control structure.
• Design and implement an algorithm that satisfies AO2 (analysis) and AO3 (design/implementation) of the A‑Level specification.
• Translate the algorithm into a clear flowchart and explain its operation in words.

What is a post‑condition loop?

A post‑condition loop executes its body first and then tests a termination condition. Because the test occurs after the statements, the loop body is guaranteed to run at least once, even if the condition is true before the first iteration.

Cambridge pseudocode syntax

REPEAT
/* statements */
UNTIL condition

Some teachers add END REPEAT for visual clarity, but the Cambridge specification only requires the three lines shown above. Use whichever style you choose consistently throughout the exam.

Key characteristics

• The condition is evaluated after each execution of the loop body.
• The loop body is executed at least once, regardless of the initial truth value of the condition.
• A loop‑control variable must be initialised before the REPEAT and updated inside the loop; otherwise the loop may become infinite.
• Typical use‑cases: input validation, sentinel‑controlled loops, “do‑something‑until‑the‑user‑says‑stop” scenarios, or any situation where the first action must be performed before a test can be made.

When to choose a post‑condition loop

• You need to guarantee that the body runs at least once (e.g. read the first value before you can test for a sentinel).
• The condition depends on data that is produced inside the loop (e.g. a running total, a counter that is incremented each pass).
• The problem description explicitly says “repeat … until …” or “do … while …”.
• Using a WHILE loop would require duplicate code to handle the first iteration.

Comparison with pre‑condition loops (WHILE)

Design & implementation checklist

1. Identify a task that must be performed at least once.
2. Initialise every loop‑control variable before the REPEAT line.
3. Place all statements that achieve the task inside the REPEAT block.
4. Update the loop‑control variable(s) inside the block so the termination condition will eventually become true.
5. Write the termination condition after UNTIL. Remember the condition is true when the loop should stop.
6. Check for the three “termination checklist” items:

   • Variable initialised?
   • Variable updated each iteration?
   • Condition moves toward true?

Step‑by‑step construction of a REPEAT‑UNTIL loop

1. Task identification: what must happen at least once?
2. Initialisation: set up counters, totals, or flags before the loop.
3. Body writing: code the statements that accomplish the task.
4. Update: modify the control variable(s) inside the body.
5. Termination condition: decide when the loop should stop and express it after UNTIL.
6. Review: verify the loop cannot become infinite and that the body will run the required number of times.

Common pitfalls and how to avoid them

• Missing initialisation – the loop may start with an undefined value. Initialise all variables before REPEAT.
• No update inside the loop – leads to an infinite loop. Ensure the control variable is changed each pass.
• Wrong condition direction – remember UNTIL condition stops when the condition becomes true. Use i > n rather than i <= n if you want to stop after the last required iteration.
• Using REPEAT when WHILE is simpler – choose the construct that matches the problem description; unnecessary use of REPEAT can waste marks.

Example 1 – Summing the first n positive integers

Compute S = 1 + 2 + … + n where n is entered by the user.

READ n
sum ← 0
i   ← 1
REPEAT
sum ← sum + i          // add current i
i   ← i + 1            // update loop‑control variable
UNTIL i > n
OUTPUT sum

Why a post‑condition loop? The first addition must be performed even if n is 0. The condition i > n is checked after the addition, guaranteeing exactly n iterations.

Example 2 – Input validation (sentinel loop)

Read integer values from the user until a negative number is entered. Store the total of the non‑negative numbers.

total ← 0
REPEAT
READ x
IF x ≥ 0 THEN
total ← total + x
END IF
UNTIL x < 0
OUTPUT total

This is a classic sentinel‑controlled situation: the first value must be read before we can test whether it is the sentinel.

Example 3 – Password entry with a maximum of three attempts

Ask the user for a password. Stop after three failed attempts or when the correct password (“ABC123”) is entered.

attempt ← 0
REPEAT
READ password
attempt ← attempt + 1
UNTIL password = "ABC123" OR attempt = 3
IF password = "ABC123" THEN
OUTPUT "Access granted"
ELSE
OUTPUT "Access denied"
END IF

The body (reading a password and counting attempts) must run at least once, making REPEAT … UNTIL the natural choice.

Link to Assessment Objectives

• AO2 – Analyse problems: Deciding that a task must be performed at least once (e.g., input validation) shows you have analysed the problem’s requirements.
• AO3 – Design and implement solutions: Translating the analysis into a correct REPEAT … UNTIL structure, with proper initialisation, update and termination, demonstrates design and implementation skills.

Exam relevance (Paper 2)

• Typical command‑style question: “Write a REPEAT‑UNTIL loop that …”. You must include the three‑line structure, correct indentation, and a condition that will inevitably become true.
• Mark‑scheme expectations:

  • Correct keywords (REPEAT, UNTIL).
  • Loop‑control variable initialised before the loop.
  • Variable updated inside the loop.
  • Termination condition logically guarantees exit.
  • Clear, indented pseudocode (usually 1‑2 marks per element).

• Students may also be asked to explain why a post‑condition loop is preferred; refer to the “When to choose a post‑condition loop” bullet list and the comparison table.

Suggested flowchart (text description)

1. Start.
2. Process box – REPEAT block (the statements that form the loop body).
3. Decision diamond – labelled “condition?”.
4. If the condition is False, arrow back to the process box (repeat).
5. If the condition is True, arrow to the End node.

This visualises the “body → test → back or exit” flow that distinguishes post‑condition loops.

Alignment with the Cambridge 9618 syllabus (2026)

The above note fully satisfies the Constructs sub‑section of the A‑Level specification (Topic 11.2). It provides the required knowledge (definition, syntax, characteristics), the analytical skills (when to choose the construct – AO2) and the design/implementation skills (writing correct pseudocode and flowchart – AO3). Other syllabus areas (e.g., data representation, networking, hardware) are outside the scope of this specific topic but are covered elsewhere in the full course notes.

Further practice

• Write a REPEAT‑UNTIL loop that finds the greatest common divisor of two positive integers entered by the user.
• Design a sentinel loop that reads a series of exam scores (0‑100) and outputs the highest, lowest and average score.
• Convert the following WHILE loop into an equivalent REPEAT‑UNTIL loop and explain why the latter might be preferable:

  WHILE NOT endoffile DO
  READ line
  PROCESS line
  END WHILE