Algorithms

1. Algorithms Recipes for disaster?

2. Topics Covered • Programming vs. problem solving • What is an algorithm? • Algorithm development • common constructs (loops, conditionals, etc) • Representing algorithms • flowcharts • pseudocode

3. 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..

4. 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

5. 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

6. 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)

7. 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)

8. 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!

9. 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!

10. 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 keyboard SET r1 = (-b + b2-4ac) / 2 Print r1 to screen

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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.

18. Algorithm Representation Examples • Flowchart:

19. 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

20. 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…

21. 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…

22. 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 module Calculate r1, r2 NOT simple, requires a module Display r1, r2 simple, not a module

23. 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!!

24. “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

25. 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…

26. 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!)

27. 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

28. Top Down Example Missile Guidance Get_inst calc_pos calc_traj calc_fin_adjst imp_fin_adjst … … …

29. 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

30. 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