Running Time - Discrete Math - Lecture Slides, Slides of Discrete Mathematics

Download Running Time - Discrete Math - Lecture Slides and more Slides Discrete Mathematics in PDF only on Docsity!

Discrete Maths

• Objective
  • to describe the Big-Oh notation for estimating

the running time of programs

4. Running Time of

Programs

Overview

1. Running Time

2. Big-Oh and Approximate Running Time

3. Big-Oh for Programs

4. Analyzing Function Calls

5. Analyzing Recursive Functions

6. Towers of Hanoi

7. Further Information

• There is no single answer!
  • the running time depends on the size of the n value
• Instead of a time answer in seconds, we

want a time answer which is related to the size of the input.

continued

• For example:
  • programTime(n) = constant * n
  • this means that as n gets bigger, so does the program time
  • running time is linearly related to the input

size of n

running time constant * n

• A typical result is:
  • T(n) = c*n, where c is some constant
    • but often we just ignore c
  • this means the program has linear running time
• T(n) values for different programs can be used

to compare their relative running times

• selection sort: T(n) = n^2
• merge sort: T(n) = n log n
• so, merge sort is “better” for larger n sizes

1 .1. Different Kinds of Running Time

• Usually T(n) is the worst-case running time
  • the maximum running time on any input of size n
• Tavg (n) is the average running time of the program over all inputs of size n - more realistic - very hard to calculate - not considered by us

Calculation

• The for loop executes n-1 times

• each loop carries out (in the worse case) 4 ops
  • test of j < n, if test, small assign, j increment
• total loop time = 4(n-1)
• plus 3 ops at start and end
  • small assign (line 2), init of j (line 3), final j < n test

• Total time T(n) = 4(n-1) + 3

= 4n -

• running time is linear with the size of the array

1 .3. Comparing Different T()’s

• If input size < 50, program B is faster.
• But for large n’s, which are more common in real code, program B gets worse and worse.

T(n)

value

input size n

Ta(n) = 100n

Tb (n) = 2n^2

1 .5. Execution Times

n 3 9 50 100 1ms 1sec n^2 9 81 2.5ms 10ms 1sec 12 days n^3 27 729 125ms 1sec 16.7 min 31,710yr 2 n^8 512 36yr 410^16 yr 310^287 yr 3*10^301016 yr log n 2 3 6 7 10 20

n (no. of instructions)

growth formula T()

if n is 50, you will wait 36 years for an answer!

Assume 1 instruction takes 1 microsec (10-6^ secs) to execute. How long will n instructions take?

Notes

• Logarithmic running times are best.

• Polynomial running times are acceptable, if

the power isn’t too big

• e.g. n^2 is ok, n^100 is terrible

• Exponential times mean sl oooooooo w code.

• some size problems may take longer to finish than

the lifetime of the universe!

Arguments against T(n)

• Algorithms often perform much better on

average than the worst case used in T()

• quicksort is n log n on a “random” array, but n^2 in the worse case
• but for most algorithms, the worst case is a good predictor of its running time
• average case analyses can be done, but they are harder mathematically

continued

• Some people say:
  • “Who cares about running time? In a few years,

machines will be so fast that even bad algorithms

will be fast.”

• History shows this argument to be wrong. As

machines get faster, problem sizes get bigger.

• Most interesting problems (e.g. computer vision,

natural language processing) always require more

resources

• fast algorithms will always be needed

continued

2. Big-Oh and Approximate Running Time

• Big-Oh mathematical notation simplifies

the process of estimating the running time of programs

• it uses T(n), but ignores constant factors which depend on compiler/machine behaviour

continued

• The Big-Oh value specifies running time

independent of:

• machine architecture
  • e.g. don’t consider the running speed of individual machine operations
• machine load (usage)
  • e.g. time delays due to other users
• compiler design effects
  • e.g. gcc versus Borland C