AlgorithmsRecipes for disaster?
Topics Covered Programming vs. problem solving What is an algorithm? Algorithm development
common constructs (loops, conditionals, etc)
Representing algorithms flowcharts pseudocode
Programming vs. Problem Solving Two very distinct tasks! Problem solving:
developing a solution to a problem result is an algorithm or a plan for the solution
Programming: converting the solution into a computer readable form (C,
assembly, VB, Delphi, etc..) Programmers are cheap – problem solvers are
not! eg, architect, engineer vs. bricklayers, carpenters, etc..
What is an Algorithm? Formal definition:
An algorithm is a step-by-step procedure for accomplishing a stated task
A recipe for solving a problem History:
derived from 9th century mathematician Abu Abdullah Muhammad ibn Musa al-Khwarizmi
initially referred only to solving arithmetic problems (multiplication, division, etc) known as algorism
definition expanded to include all mathematical procedures formalised by Alan Turing in 1936 (Turing Machine) the foundation of computer science
Algorithm Examples Humans solve problems intuitively without
usually formalising the steps involved Consider:
passing this course making a cup of tea multiplying two numbers determining if a number is prime finding the largest number in a list
Properties of Algorithms Finiteness: must eventually terminate Definiteness: each step is precisely defined, there
is no ambiguity Input: information which is required in order to
start the algorithm Output: result of the algorithm, with some relation
to the input Effectiveness: should be able to be emulated
manually (paper and pencil)
Types of Algorithms Iterative or Recursive:
recursive algorithms call themselves, iterative algorithms do not Serial or Parallel:
one instruction at a time or multiple instructions Deterministic or Stochastic:
identical execution for identical input or some randomness involved
Exact or Approximate: is the solution exact or merely good enough
Complexity: how long the algorithm takes to run (for a given size input)
Algorithmic Constructs There are a number of standard ‘tools’ used when
developing algorithms variables statements loops conditional statements modules
These are the same actions we use for every activity you just don’t realise it!
Variables Variables are areas of storage used to keep track of data
in an algorithm, the size or type of the data in a variable is not necessarily defined, but should be consistent
can hold numbers, letters, words, etc.. Each variable requires a distinct name
should be related to what the variable is holding, eg. age, iq, student_number, etc
The equivalent of writing something down for later when manually running through an algorithm, it is helpful to use
labelled boxes for variables Input/Output values are also considered variables Variables are the only data that is available to the algorithm!
Statements Statements are the building blocks of algorithms
each statement is an instruction to perform an action set or change a variable’s value perform calculations write data to the screen, read from keyboard call another module
Statements should be either: simple, atomic actions that are easily understood module calls which are defined elsewhere
ALL relevant information needs to be included in the statement!
Read a, b, c from keyboardSET r1 = (-b + b2-4ac) / 2Print r1 to screen
Conditional Statements Most non-trivial algorithms are not simply a
sequence of statements require some decisions at some point!
Conditional statements are used to branch the execution of an algorithm logical expressions are used to make such decisions
IF ( something is true ) THEN do something
ELSE do something else
Loops and Repetition Most algorithms require some actions to be
repeated numerous times, either: a fixed number of times, OR until a condition is met (or no longer met)
Such constructs are known as loops, and are a powerful tool in algorithm design
Representing Algorithms Algorithms can be represented in numerous ways
plain English descriptions graphically (flowcharts, Nasi-Schneiderman diagrams, etc) structured English (pseudocode)
Each approach has advantages and disadvantages ease of understanding ambiguity speed of creation ease of conversion to actual source code
Plain English Descriptions As name implies, a plain language description of
the algorithm Usually in the form of an English paragraph Advantages:
easy for layperson to understand quick to create
Disadvantages: often ambiguous does not convert easily to code no well defined structure, so large variations between
authors
Graphical Representations Visual representation of algorithm
each structure has a set of symbols to represent it Flowcharts are one of the earliest and most popular forms
boxes = actions diamonds = decisions arrows = program flow
Advantages: some people find visual approach easy to understand unambiguous
Disadvantages: can be large and difficult to create direct conversion to code is possible, but not always simple
Structured English Known as pseudocode A cross between English and program language
rules, conventions and structures similar to programming languages
statements are written in plain English statements Advantages:
very easy to convert to program code unambiguous in most cases
Disadvantages: not as easy to read as plain language can be ambiguous if written poorly
Algorithm Representation Examples
Simple directions to a destination: Plain English:
Go straight on to the traffic lights, turn left and take the third turning on the right. If the red gate is open then go through it, otherwise go through the green gate.
Algorithm Representation Examples
Flowchart:
Algorithm Representation Examples Pseudocode:
Go straight on to the traffic lights
Turn left
Take the third turning on the rightIF the red gate is open THEN go through the red gateELSE go through the green gateEND IF
Examples Reconsider these problems:
passing this course making a cup of tea multiplying two numbers determining if a number is prime finding the largest number in a list
Now define a solution in each representation…
Breaking Down a Problem Problems are often too complicated to be completely defined
in a single algorithm In such cases, some steps are defined only in general terms
add milk to tea study determine factors of x
Such tasks are not simple cannot be done in one action – one line of code
This is OK, provided that they are expanded upon elsewhere This is known as a modular approach, and is how all large
software systems are developed each module is designed and built separately, and assumes the
other modules will do their job…
Modular Algorithm Examples Traditional program breakdown:
get input process input display output
For very simple problems all such steps can be done in one algorithm
For more complex tasks, each step becomes one or more modules eg, solving quadratic equation:
Read a, b, c simple, not a moduleCalculate r1, r2 NOT simple, requires a moduleDisplay r1, r2 simple, not a module
Defining Modules When modules have been identified, it is
necessary to define them What is required?
inputs outputs their own algorithm!
Note that the calling module doesn’t need to know the algorithm but does need to know the inputs and outputs!!
“Top-Down” Design Systematic method of algorithm
development start at a high, conceptual level specify operations in general terms identify sub-modules
inputs, outputs repeat for each sub-module
Can benefit from re-use of some common modules
Top Down Example Missile guidance system Basic algorithm:
inputs: target coordinates (t_location)
while ( haven’t hit target yet )get instrument readingscalculate position and directioncalculate required trajectorycalculate fin/motor adjustmentsimplement adjustments
end while
Clearly, all statements here require some refinement…
Top Down Example Get_instrument_readings
outputs: gps, speed, altitude, gyro
activate gpsget gps informationread speedread altitude from altimeterread spin from gyroRETURN ( gps, speed, altitude, spin )
Calculate_position_and_velocity input: gps, speed, altitude, spin output: position, velocity
Algorithm: who knows?!? (somebody else’s job!)
Top Down Example Calculate_trajectory
inputs: position, velocity, t_location outputs: req_trajectory
Calculate_fin_motor input: position, velocity, req_trajectory output: fin_adjust, motor_adjust
Implement_adjustments input: fin_adjust, motor_adjust
Top Down Example
MissileGuidance
Get_inst calc_pos calc_traj calc_fin_adjst imp_fin_adjst
… … …
When to Break Down Problem? In general, an algorithm (module) should be no more than 20 lines
long >20, probably should be modularised not a hard and fast rule, but a guideline – many ‘simple’ modules may
contain hundreds of lines Any moderately lengthy section of an algorithm which is used a
number of times should be made into a module Modules should be logical!
well-defined purpose (make sense independently) the module should be cohesive not just to break apart a long module!
Modules should be able to be tested independently! must have a good input/output relationship testing is done before integration occurs
Types of Modules Some languages define different module types Procedures:
perform a specific task do NOT provide an output can take inputs however
Functions: return at least one output in general, their purpose is to calculate those values, and
nothing else can of course take input as well
C makes no distinction between these types of modules – all are called functions