Exam II:
Next Tuesday, about 18 questions.
Core reading, code writing, short answer.
Focus on chapters of both books since last exam (see schedule page for details).
If you have any last minute questions, email me or the TAs.
Course evaluations:
UTK SAIS online course evaluation is up and open for business. Please do that. It's
useful information to us.
Also, for CS102 (and ECE 206) we have an additional survey, which gives us
additional information on how we are teaching CS102. Some of you filled out an
online survey at the beginning of the semester. Whether you did or not we request
that you do the end-of-semester survey. We'll send out the URLs for the surveys in
a day or two. It is completely voluntary, but it will help us if you do it.
Return your robot kits!!
Look for a file called "More C++.pdf", which tells you a few more things about C++
that you are likely to need to know in followon CS classes. It's on the website and
I'll send an email.
Algorithms:
Basic elements of an algorithm (LCR 306):
1) Algorithms are step-by-step recipes that clearly identify inputs and outputs.
You can describe algorithms in many different ways: English, math, diagrams (e.g.,
flowcharts), pseudocode (mixture of English and some PL notation), etc., so long as
it is sufficiently precise. Basically what "sufficiently precise" means is that it should
involve no judgment, or skill, or detailed knowledge. In principle, the instructions
are precise enough that a very dull person or machine can carry them out. The idea
is that if you carry the operations carefully, you are guaranteed to get the right
answer.
(Recall, the the word "computer" originally referred to a person; it was a job
description. Early machines for computing were called "automatic computers.")
To run an algorithm on a (automatic) computer, you have to translate it into a PL,
and then you have a program. Describing an algorithm in pseudocode keeps it
independent of a particular PL or computer, but we have to be careful that we use
only operations that are "mechanical."
2) Algorithms name the entities that are manipulated or used, e.g., variables,
functions, classes.
3) Steps of an algorithm are followed in the order they are written. (More
specifically, the steps in a function are followed in order. Invoking a function can
jump to another part of the program.)
4) Some of the steps specify decisions (if-then-else, switch) of the choice of steps.
5) Some of the steps specify repetition (loops) of steps. (This includes recursion.)
6) All of the above can be combined in any fashion (subject to certain rules of
syntax).
Because of the above common features of algorithms, any program in one PL can
be translated into a program in another PL. In this sense all PLs are equally
powerful. However, some algorithms may be much easier to express in some PLs
than others; some PLs are more efficient for some or most programs than other
PLs; some PLs are easier to read than others; some PLs are more reliable to
program in; some PLs encourage or discourage good programming practices; some
are better for very small or very large programs, etc.
As we've said, there are thousands of PLs. You can't know them all. Unless your
relation to computers is going to be very casual, you can't get by with knowing just
one. Chances are, over the course of you career, you will have to learn several PLs.
Developing an Algorithm:
1) It's often a good first step to think about doing it by hand. What are the steps?
What are he decisions you make? What scratch paper etc. do you need to make
notes on? Think about describing it to a very dull person who really doesn't
understand the purpose of the algorithm. This helps you to see the steps and the
information you need to keep track of to complete the algorithm. Work through
several examples.
Remember: "If you choose the data structure well, the algorithm will design itself."
Notice the data structures (arrangements of data, diagrams, etc.) that make the
algorithm easy to carry out, and design analogous data structures for the computer.
2) Look for common patterns. These will often become loops or functions in your
program.
3) Think carefully about general and special cases.
4) Write it out carefully in English, pseudocode, a diagram, etc. Look for
ambiguities, incompleteness (cases not covered), etc.
At this point you have an algorithm that you believe to be correct.
5) Testing. This is easiest with a computer, which means you have to translate your
algorithm into a program. This is a mixed blessing, because if it doesn't do the right
thing you may have to debug the program. One way to debug the program is to
"play computer," that is, execute by hand. Then, if you understand your algorithm,
you can see where things start going wrong.
6) Start with simple examples, which you can check by hand, and for which you
know the right answer.
7) Make sure to test on boundary conditions. Your knowledge of the algorithm can
help you decide what they are. Try data that exercises every path in the program.
Test it on bad data.
Software Engineering:
This is mostly just good engineering principles applied to software development.