Hardware - Griffith University
Download
Report
Transcript Hardware - Griffith University
Algorithms
Recipes 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:
Programming:
developing a solution to a problem
result is an algorithm or a plan for the solution
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:
Serial or Parallel:
identical execution for identical input or some randomness
involved
Exact or Approximate:
one instruction at a time or multiple instructions
Deterministic or Stochastic:
recursive algorithms call themselves, iterative algorithms do not
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
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
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..
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
Statements should be either:
set or change a variable’s value
perform calculations
write data to the screen, read from keyboard
call another module
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 keyboard
SET r1 = (-b + b2-4ac) / 2
Print 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
Flowcharts are one of the earliest and most popular forms
boxes = actions
diamonds = decisions
arrows = program flow
Advantages:
each structure has a set of symbols to represent it
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
Advantages:
rules, conventions and structures similar to programming
languages
statements are written in plain English statements
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 right
IF the red gate is open THEN
go through the red gate
ELSE
go through the green gate
END 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
Such tasks are not simple
add milk to tea
study
determine factors of x
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
Calculate r1, r2
Display r1, r2
simple, not a module
NOT simple, requires a module
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 readings
calculate position and direction
calculate required trajectory
calculate fin/motor adjustments
implement adjustments
end while
Clearly, all statements here require some refinement…
Top Down Example
Get_instrument_readings
outputs: gps, speed, altitude, gyro
activate gps
get gps information
read speed
read altitude from altimeter
read spin from gyro
RETURN ( 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
Calculate_fin_motor
inputs: position, velocity, t_location
outputs: req_trajectory
input: position, velocity, req_trajectory
output: fin_adjust, motor_adjust
Implement_adjustments
input: fin_adjust, motor_adjust
Top Down Example
Missile
Guidance
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
Any moderately lengthy section of an algorithm which is used a
number of times should be made into a module
Modules should be logical!
>20, probably should be modularised
not a hard and fast rule, but a guideline – many ‘simple’ modules may
contain hundreds of lines
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:
Functions:
perform a specific task
do NOT provide an output
can take inputs however
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