The differences between:
- Getting the job done
- Doing the job right, and
- Doing an excellent job
|
In ICS111 we learned how to program. We
made our programs work no matter how. "The end justifies the means".
By the time that we reached ICS211 we learned to recognize that there are
more than one way to get things done. There are ways to make things work fine,
but the way the program is coded is embarrassing, while there are also
programming strategies and coding standards that make us proud of our code.
Today we will talk about the different ways in which we can get things done.
This topic can be found in the book in
Appendix B. However as I'd been mentioning in class not all the material
in the book is going to be in the exam what is in the exam is what we
talk about in class. Appendix B is very long and contains material that you may
not yet be familiar with. PLEASE, do not worry about all the material
presented here. What we will be looking at is an introduction and as the course
evolves we will apply this concept until we get comfortable with it.
Topics for May 25, May 30th
2000
Please refer only to the sections of
the book mentioned here.
-
using O-notation to compare
efficiencies of algorithms. (page 452)
-
Some limitation of Big-O. (page
452)
-
Definition of benchmark
(page 453)
-
The effects of using different
compilers (page 454)
-
Introducing the language of Big-O
notation. (page 459 Table B.7)
-
Circumstances in which O-notation
doesn't apply. (page 470)
Introducing the language of Big-O
notation
|
Adjective Name |
O-notation |
| Constant |
O(1) |
| Logarithmic |
O(log n) |
| Linear |
O(n) |
| n log n |
O(n log n) |
| Quadratic |
O(n^2) |
| Cubic |
O(n^3) |
| Exponential |
O(2^n) |
| Exponential |
O(10^n) |
Algorithm Analysis
Class slides
January 20, 2000.
Definition
- Measuring the amount of work as it varies with the size of the data
affected
- Predicting the expected overall performance of an algorithm
- Generally measured relative to other algorithms to handle the same
problem
Measuring algorithm performance
- Usually not expressed in absolute units of measurement
- Expressed as approximate rate of growth of work as size of data
grows
Possible concerns
- Best case performance usually NOT an issue
- Average case performance may or may NOT be relevant
- Worst case performance usually primary issue
Big-O notation
- Method for estimating algorithm performance
- Estimates RATE of algorithm growth rather than measuring actual
time/space
resources used
- Does NOT give exact measurements.
Determining Big-O measures
- Disregard any work which takes a constant amount of time regardless
of
amount of data involved.
- Determine how the time required by repetitive work grows as the size
of
data grows.
- Take into consideration iterations/recursions.
- For multiple repetitive structures, determine the measure for each
and
then evaluate the relationship.
- Nested relationships-- multiply the relationships
- Sequential relationships -- add the relationships.
Order 1 Algorithms
- O(1)
- Algorithm takes the same amount of time regardless of the number of
data
items involved
- Example: Retrieval of a single data item from an array, when you
know
where the data item is.
Order N Algorithms
- O(N)
- Time required for algorithm grows linearly as number of data items
(N)
grows
- Example: Worst case efficiency of performing a sequential search
for a
data item in an array.