Outline

• Course plan
• Course definition for an algorithm
• Different between instructions, algorithms, processes
• Expressing algorithm
• Problem specification
• Algorithm Correctness
• Loop invariant
• Counter examples
• Reason for the analysis of an algorithm

Objective

• Understand terms and methodologies in Computer Science
• Know the origin of the word “Algorithm” and its informal definition
• Differentiate between step-by-step instructions / algorithms / processes
• Identify the specification of a problem
• Prove the correctness and give counter examples
• Give reason for the analysis of an algorithm

Practical algorithm

In practice we want algorithms that are:

• Correct
• Efficient
• Easy to implement

Specification

• An algorithm is an implementation of a solution to a problem
• We need a way to specify a problem so we can design algorithms to solve it.
• A computer program is a translation of an algorithm into a particular programming language (also an implementation)
• Checking that an implementation correctly executes an algorithm is the realms of software engineering and formal methods
• We are interested in the design and analysis of algorithms
• We don’t care what language it is subsequently implemented in
• But we do need a language to express algorithms

Q: Why don’t we always use English? Why don’t we program computers in English?

Simple Specification

• Definition: A simple specification is a pair of predicates, one describing the starting states, the precondition, and one describing the associated final state, the postcondition.
• Factorial computational problem:
  Precondition: $n \in \mathbb{N}$; Postcondition: $r$ = $n!$
• Sum from 1 to n computational problem:
  Precondition: $n \in \mathbb{N}$; Postcondition: $r$ = $\displaystyle\sum_{i = 1}^{n} i$.
• Preconditions and postconditions are like a contract between the caller and the algorithm:
• Algorithm: “If you ensure the precondition is satisfied, I’ll guarantee that the postcondition is satisfied upon termination”
• Caller: “Ok, and if I don’t ensure the precondition is satisfied I’ll make no assumptions about what your behaviour will be”

GCD Specification

• Let’s think up pre/postconditions for the greatest common divisor algorithm:
• Precondition: $m, n \in \mathbb{N} \& (m > 0) \mbox{ and } (n > 0)$
  Postcondition: $(r|m)$ and $(r|n)$ amd $\forall i \in \mathbb{N}; (i|m) \mbox{ and } (i|n) \rightarrow i \leq r$.

Certifying GCD Algorithm

• Sometimes preconditions and postconditions can be easily checked
• Many programming languages support assertions – good practice to check pre/postconditions, example:

Function GCD(m; n:N):N
1. assert (m > 0) & (n > 0)
2. if m < n then
3.    (m; n) := (n, m)
4. while n > 0 do
5.      r := m mod n
6.     (m; n) := (n; r)
7. endwhile
8. assert (r|m) & (r|n) & (all i, i|m & i|n → i < r)
9. return m

Certifying Algorithms

• This might seem a bit circular – isn’t checking the postcondition as hard as running the algorithm in the first place?
• In many situations checking assertions can be simplified by computing additional information – a certificate
• A certifying algorithm computes a certificate for the postcondition
• We will see examples of algorithms later where a certificate can be computed without affecting the efficiency of the algorithm

Loop invariant

• A loop invariant is a statement which is true before and after each loop iteration
• Used to help prove program correctness
• Helps to clarify purpose of iterative structure
• Loop variant ensures progress is made

Function sum(n:N):N
1. assert (n > 0)
2. s := 0
3. for i := 1 to n do
4.       s := s + i
5.       invariant s = sum j from 1 to i of j
6. endfor
7. assert s = sum i from 1 to n of i
8. return s

Reasoning about correctness

• We need to know whether our algorithm will always work, i.e. produce the correct/optimal answer.
• Let’s look at an example:

  Robot Tour Optimization

  Robot arm must visit a set of contact points on a circuit board to solder each point Need to choose an order in which the contact points will be visited We want to minimise time taken, i.e. shortest path Shorter tour = faster production = cheaper to produce = more profit

Nearest neighbor heuristic

Input: A set $P$ of $n$ points
Output: The shortest cycle tour that visits each point

• Simple idea: nearest neighbor tour
• Use a heuristic – pick any starting point, then next move is always to nearest point

Counter tour example

A better (optimal) solution for the same instance:

• It can be easy to prove that an algorithm is not correct – just find a counter example (the simpler, the better)
• Counter example = instance of problem + optimal solution + demonstration that algorithm produces a less optimal solution
• Lack of a counter example doesn’t prove it works
• We will not study the formal methods to prove correctness of our algorithms
• Instead, we will informally convince ourselves that they work

Specification and correctness

As algorists, we need tools to:

• Specify a problem so we can design algorithms to solve it and strategies to design algorithms which satisfy specifications
• Distinguish correct algorithms from incorrect ones
• Check that the algorithm satisfies the problem specification
• Compare algorithms and choose the “best” one
• There may be many alternative algorithms that satisfy a specification
• We want the one that is “best” for our purposes
• Often, best = most efficient. Is this always the case?
• The subject of much of this course!

Conclusion

• What an algorithm is
• How to specify a problem
• How to show algorithm incorrectness by counter example
• Some justification for why algorithm analysis is important

Comments and Suggestions

• Assistant Professor Krung Sinapiromsaran
• Web: http://pioneer.netserv.chula.ac.th/~skrung
• Email: Krung.S@chula.ac.th