DESIGNING, CREATING AND
REFINING ALGORITHMS
REPRESENTING ALGORITHMS
• An algorithm is a set of instructions that describes how to solve a problem.
• Algorithms can be designed using pseudo-code and/or flowcharts. They are
written using statements and expressions.
• Whether algorithms are designed with pseudo-code or flowcharts, the focus is
on the logic of the steps instead of the programming language because
programmers should be able to translate an algorithm into any programming
language, for example, from Python to C++.
• This is known as being language independent.
REPRESENTING ALGORITHMS
Psuedo-code
Pseudo-code is a simple way of describing a set of instructions in a manner that
resembles a programming language. In an algorithm, most processes fall into three
main categories:
• inputs
• processes
• outputs
When pseudo-code is being written, inputs, processes and outputs can be identified
using the key words in the code.
EXAMPLE OF PSEUDO-CODE
the times table up to ten:
num ← USERINPUT
FOR number ← 1 TO 10
OUTPUT number * num
ENDFOR
FLOW CHART
A flowchart is a diagram that shows an overview of an algorithm. Flowcharts
use a variety of standard symbols to represent different elements, and arrows
to show the flow or direction. These symbols are used to construct the
flowchart and show the step-by-step solution to the problem.
FLOW CHART
NAME SYMBOL EXPLAINTION
Start / Finish Used to indicate the start and
finish of the algorithm.
Process A process / action to be
performed, e.g. a calculation
or the assignment of a value.
Input / Output Used to show data being
inputted into the system (e.g.
by a user), or data being
outputted (e.g. a message or
the value from a variable).
Decision A question / test of a condition
that allows the flowchart to
branch into one of two paths,
yes or no.
Line Line is used to tell the flow
EXAMPLE OF FLOW CHART
DECOMPOSITION
Decomposition is breaking a problem down into smaller, more manageable
chunks. In programming, this means breaking down an algorithm into smaller
problems that can be solved on their own.
For example, using the times table problem from the previous page, this could
be broken down in the following way:
Output times table to ten
Get user Output the
Calculate input*count
input user
EXAMPLE
In larger programs, problems are decomposed further until it is easy to identify
how each could be written as an individual subroutine in the program. This is
useful to a development team, for example, as it means that the work can be
divided between them. As the problem has been broken down into smaller
sections, the subroutines can be reused to solve similar problems.
ABSTRACTION
Abstraction is the process of removing unnecessary detail from a problem so
that the important details can be focused on. This can make solving the
problem easier.
An example of abstraction is the London Underground map. It details tube
lines, services that run on them and the stations. This is all that is required for
a passenger to be able to plan a journey from one station to another. Other
details, such as real geographical location, distance between stations, depth
underground and number of platforms are not included as they are irrelevant to
journey planning on the Underground.
DETERMINING THE PURPOSE OF
SIMPLE ALGORITHMS
When given an algorithm, there are a number of ways to determine what the
purpose of the algorithm is. Sometimes it is clear as the algorithm is simple;
however, at other times it is useful to ‘dry run’ the algorithm to see what is
taking place.
Dry running an algorithm means to assign the values to variables of an
algorithm and to do any processing that takes place without translating it into
code.
Two ways to Dry run are:-
Trace tables
Visual inspection
TRACE TABLE
Trace tables enable the variable values in an algorithm to be recorded as the algorithm is dry
run.
For example, using the times table algorithm below, a table could be created showing
the value of the variables num and number as the program runs:
NUMBER NUM OUTPUT
num ← USERINPUT
1 5 5
FOR number ← 1 TO 10
OUTPUT number * num 2 5 10
ENDFOR 3 5 15
4 5 20
5 5 25
6 5 30
7 5 35
8 5 40
9 5 45
VISUAL INSPECTIONS
Some algorithms follow a pattern that can be recognized. Many of these are
referred to as standard algorithms and often follow a set pattern for searching
for or sorting data. Sometimes it is clear what this is just by looking at
the pseudo-code. For example, the algorithm below follows a recognisable
pattern for searching through each letter of a word and checking if the letter
entered matches. This would be a useful decomposed part of a hangman game.
guess ← USERINPUT
FOR i ← 0 TO LEN(word)
IF word[i] = guess THEN
OUTPUT “found”
ENDIF
ENDFOR
EFFICIENCY OF ALGORITHMS
Not all algorithms are made equal and it is a computer scientist’s job to
consider the patterns and features that would find the best solutions to
problems.
For example, sorting data into alphabetical order could be completed using a
number of different methods. The programmer could choose to use bubble
sort or merge sort, which are both standard sorting algorithms - but before
choosing, it would be important to know which would be most efficient. You can
read more about sorting algorithms in the common algorithms guide.
Efficiency looks at how much time it takes to run a particular algorithm and
how much space is needed. By using both measurements, an algorithm that
looks much more complex can actually be more efficient.
EFFICIENCY OF ALGORITHMS
Efficiency looks at how much time it takes to run a particular algorithm and
how much space is needed. By using both measurements, an algorithm that
looks much more complex can actually be more efficient.
In the example of sorting data, the programmer might choose to look for the
smallest piece of data and put that at the start of a new array, then repeat the
process until all the data has been removed from the original array. This would
certainly solve the problem, but there are better ways to reach the goal. These
would be described as being more efficient.
