Designing, creating and refining algorithms

Before an algorithm can be written, the problem has to be defined. The standard first step is to identify three things:

• Inputs — the data the system receives, whether typed by a user, read from a file or taken from a sensor • Processes — the calculations, decisions and manipulations carried out on that data • Outputs — what the system produces: something displayed, printed, saved or sent to a device

For a program that works out a customer's change: the inputs are the total cost and the amount paid; the process is subtracting one from the other, and checking whether enough money was given; the output is the change due, or a message that the payment is short.

A common trap is listing something as an input when it is actually stored in the program. A price looked up from the program's own list is not an input — it was not received from outside.

A structure diagram shows decomposition visually. The whole problem sits in a box at the top, and below it are the sub-problems it breaks into, each of which may break down further. It is a hierarchy read top to bottom.

You are required to produce simple diagrams showing the structure of a problem, and the subsections and their links to other subsections — so the links matter as much as the boxes, and every box must connect to its parent.

A flowchart expresses an algorithm as a diagram. Each symbol has a fixed meaning, and using the wrong shape loses marks even when the logic is right.

How to read them:

• Terminal — the rounded box at the start and end, labelled START or STOP • Input/Output — the parallelogram, for anything entered or displayed • Process — the rectangle, for a calculation or an assignment • Decision — the diamond, containing a question with two labelled branches, Yes and No • Sub program — the rectangle with vertical bars at the sides, for a task defined elsewhere • Line — an arrow showing the direction of flow

The decision symbol is where loops come from: if one branch leads back to an earlier point, the steps in between repeat until the condition changes — a condition-controlled loop drawn as a diagram.

The specification asks you to create, interpret, correct, complete and refine algorithms — five different demands, and papers use all of them. Algorithms may be given as pseudocode, as flowcharts, or in a high-level language or Exam Reference Language.

Exam Reference Language is close enough to ordinary pseudocode that no new syntax has to be memorised, but knowing the common forms saves time.

Nesting means putting one structure inside another, and the specification names it explicitly for both selection and iteration.

Nested selection is an if inside an if — checking a second condition only when the first was true. Nested iteration is a loop inside a loop, which is how a two-dimensional array is processed: the outer loop moves through the rows and the inner loop moves through each column of that row.

When writing nested code, indent every level. The indentation is not decoration — it is what makes it possible to see which endif or which next belongs to which structure, and unindented nested code is where most logic errors hide.

You are expected to identify syntax and logic errors in code and suggest fixes.

A syntax error breaks the rules of the language, so the program will not run at all: a missing endif, a misspelled keyword, an unclosed quotation mark or bracket.

A logic error runs perfectly but produces the wrong answer: using + where * was meant, a loop running one time too many, a condition using > when it should be >=, or a total not reset to zero before it is accumulated.

When asked to suggest a fix, say what is wrong and what it should be — “line 4 uses = instead of ==, so it should read if answer == 5 then” earns the mark that “there is an error on line 4” does not.

A trace table follows an algorithm by hand, recording the value of every variable after each step. It is how logic errors are found without running the code, and you must be able to both create and use them.

The method: one column per variable, plus a column for any output. Work through one line at a time, and write a new row every time a value changes. Do not skip iterations of a loop — the point is to see what happens on each pass.