Algorithmic Thinking

AQA 4.4.4 — Thinking logically: algorithmic thinking

Retrieval: you now have three tools from this sequence — abstraction (what matters), decomposition (break it down), pattern recognition (has part of this been solved before). Algorithmic thinking is where they come together: using logical reasoning to actually design a step-by-step solution for a problem you haven't been given a ready-made algorithm for.

Worked example — designing a car park barrier algorithm

Problem: a car park barrier should let a car enter only if there's a free space, and should always let a car exit.

Applying decomposition first: this splits into "handle entry requests" and "handle exit requests." Applying logical reasoning to the entry case:

Check whether the number of occupied spaces is less than the total capacity.
If there is space, increase the occupied count by one and raise the barrier.
If there is no space, keep the barrier down and display "Full."

def car_park_decision(occupied, capacity, action):
    if action == "enter":
        if occupied < capacity:
            return occupied + 1, "Entry allowed"
        else:
            return occupied, "Entry denied - car park full"
    elif action == "exit":
        return occupied - 1, "Exit allowed"

Common mistake

Designing an algorithm that only handles the "happy path" — the case where everything goes as expected — and forgetting the edge cases and constraints that a real system must also handle. The car park algorithm above is only correct because it explicitly checks for the full-car-park case; a version that just always incremented the count on entry would eventually allow more cars in than there are spaces.

Justify your design

For the car park algorithm above, justify this specific design decision: why does the algorithm check occupied < capacity before incrementing, rather than incrementing first and checking afterwards? What would go wrong with the second approach?

(Checking first prevents the occupied count from ever exceeding capacity, even briefly. Incrementing first and checking afterwards would let the count go one over capacity before the algorithm "notices," which could allow the barrier to briefly report an invalid state.)

Cumulative retrieval — from Sequence 5

Binary Search (Sequence 5) is itself a ready-made example of algorithmic thinking, even though it wasn't framed that way at the time. Decompose it now, explicitly: (1) what is the repeated logical check at each step (comparing the middle value to the target)? (2) what is the decision made from that check (search the left half, the right half, or stop)? (3) what is the constraint the algorithm depends on that, if violated, breaks it completely (the data must already be sorted)? Stating Binary Search this way — as a sequence of checks, decisions and constraints, exactly like the car park algorithm above — is precisely what "algorithmic thinking" was retrospectively doing all along.

Apply it — design your own algorithm

Using decomposition and logical reasoning, design a step-by-step algorithm (in structured English or pseudocode) for a library self-checkout system: a book can be borrowed only if it's currently available, and returning a book should always succeed. Explicitly identify at least one constraint your algorithm must handle, beyond the straightforward case.

Challenge

Implement your library self-checkout algorithm in Python, then test it against both the straightforward case (a book that's available) and the constraint case (a book that's already borrowed) to confirm your design decision from the "Apply it" task actually works as intended.

Looking ahead: the next lesson (Evaluation of Computational Solutions) asks you to critically assess algorithms and programs like the ones you've just designed — including your own.

Learn