|
|
To the Code Lair |
ALL GOOD THINGS must come to an end; and on 5 June 1999, this page was updated for the final time.
Please Note
Please doublecheck your grades, posted below. If something needs to be modified, please notify me by Monday so I can fix it.
If you don't reach me by then, let Dr. Osborne know as soon as possible so it can be fixed.
Additions, of Varying Degrees of Newness
Still Fresh
Ancient History
Sending your Labs
Please send your labs to (dead e-mail address)
as an e-mail attachment. Please include your .cpp source file(s) and
your self-evaluation (preferably in Microsoft Word .doc format - .rtf, .wpd and plain ASCII text
are OK too). Please do not
include the executable file or the workspace description (.dsw) file. These
greatly increase the size of the ZIP for no reason; I can compile the source perfectly well
on my machine... or can I? :)
Labs are due by 8 am the Saturday after the lab.
Here's a little blurb that wasn't here before... just to see if you're reading the page. Exciting, isn't it?
You should hear from me within a couple days after sending in your lab. Grades will be posted on this page (indexed by student number), along with graphs and similar amenities, every week.
(Large table of grades removed)
Lab Notes
This lab went extremely well; the average was very high (although I expect this will change somewhat before the end of the quarter.) There were a couple of recurring questions: by far, the most common was what does n choose k mean? There was also some confusion as to the proper output for the visualized recursive factorial; I allowed for some variation here, as long as the output could reasonably be interpreted in terms of the somewhat discombobulated instructions in the book.
Recursion is a very valuable tool, and every prospective professional programmer would do well to master it. Many functions that would be very time consuming, compilicated, or simply boring to write iteratively can be efficiently defined recursively in only a few lines of code.
Here are two interesting examples of computer art that were generated using recursive algorithms for the Mandelbrot set and the fractal fern. Follow the links to learn more about these fascinating, practical, and aesthetically pleasing uses of recursion. (Both links seem to be dead now.)
(You might ask what's so great about the Mandelbrot Set. Go here
(this one's dead, too)
and try exploring around. One of the neat things about fractals is no matter how
closely you zoom in, there's always another level of intricate detail to discover.
That's because they're defined recursively. Isn't it neat?)
And finally, a recursive joke:
Alf: Did you hear about the computer scientist who died in the shower?
Ralph: No; what happened?
Alf: His shampoo said, "Rinse, lather, and repeat."
Another successful lab: most of the questions this time centered on sorting the array of names in part b. Most students were able to finish with little trouble.
Another question I received from several quarters was what the heck do I need srand() for?
However, although there have been many questions about the labs, I have not had many about the quickly approaching Program 1. I hope this is because everything is going nicely.
A very troublefree lab this was. You were given code to start with and basically translated all references to arrays to the equivalent pointer expression.
Since pointers are going to become your best friends (before you know it,) here's a very goofy page you might enjoy: Pal the Pointer.
It's a sad fact. But at your level of experience, you simply cannot afford to start a program lately, and then run into some difficult hurdle. It'll keep you up all night. It's not good for your health. And in the end, it'll almost certainly hurt your grade.
Although most of you did well on this program, many of you felt time pressure. This was by far the number-one problem with this assignment. And most of those who did have problems could've solved them had they had more time.
Remember, the next program will be worse. So if you felt rushed with this one in any way at all, for heaven's sake, start sooner on this one!
If you start a program early:
1. You'll be able to get help from Dr. Osborne, me, or one of the other TAs instead of having to tear your hair searching for a last minute answer in the textbook (good luck.)
2. You'll be sure to catch every last bug and compare the operation of your program carefully to Dr. Osborne's specifications... instead of simply getting it "running."
3. You'll be able to focus your attention on the new material presented in class every day. Since programming is an incremental skill, it is vitally important that you learn and understand every new topic!
4. You'll be finished long before your classmates, and will be able to romp and play in the beautiful sunny weather while they type frantically in the dungeons of Haggard Hall.
5. You'll make me very happy and there'll be accolades and shooting stars and dancing and... well, maybe not. But you get the point.
Once again, code was provided for you to start with. In general, there were few problems with this lab.
You probably don't have any idea how nifty these things called "classes" are yet. However, you may take it from me that they will make your life a lot happier. You will be very proud to have these in your "programming toolbox", and you'll be surprised how little incentive you'll require before drawing them thence and showing them off to all your computer buddies. No, really. These are great things. Get excited. Study them carefully. Learn how to use them. (Learn how not to use them.)
Like any tool, they are useful only when you know when, where and how to apply them... but once you've figured out their operation, you'll be surprised the things that you can do.
Do I sound like these "classes" are a big deal? Well, they are. They help you to describe real-world things in a way the computer understands. They help you break your code down into little modules, each communicating with each other, and only operating on the data they should be. (Amazing how many errors this can help catch.) They help you objectify your problem to any degree required... and then, you can destroy, destroy, destroy!
Whew! Maybe it wouldn't be a good idea to give a programmer power.
I thought it would be high excellent-efficient to grade Program 2 and Lab 5 together. This turned out nice for the program, but it meant you wound up getting your labs a little later than you were used to. (Though getting your program grade Monday evening - as many of you did - must've been nice.)
I am happy to say that most students did learn from Program 1, and were sure to get started quickly. (I even got a few programs early. Good brave folks, those. Highly commendable.) And as a rule, you impressed me with your programming prowess.
With this trend, I'm sure the Program 3's will be absolutely stellar. But don't rest on your laurels... keep up the pace!
Where was everybody with this lab? I saw Poli and one or two others, but there's twenty people in this section! C'mon, guys, don't leave me lonely in the murk of HH 122 at 8:00 in the morning! It's cruel!
So, come to labs every week... or I'll put up another Pal the Pointer page!
I think everybody did rather nicely on this lab. Dr. Osborne gave you all an extension (which explains why this page is being updated today rather than last night.)
The lab was relatively straightforward, although there was a little confusion on the difference between the declarations
Array Array::operator+(const Array &a)
and
Array &Array::operator+(const Array &a)
If you use the first declaration, you may return your local Array object
with ease... the program automatically generates a copy and actually returns
that.
But if you use the second declaration, your program won't work. That's because it actually returns the local variable... which, due to the rules of scope, is destroyed on exiting the function. Your compiler should complain. If it doesn't, you're pretty much guaranteed to get junk when you try to execute the program.
There was also confusion on the difference between
Array operator+(const Array &a)
and
Array Array::operator+(const Array &a)
The first is an attempt to define a unary (takes one argument) addition operator, which
doesn't exist. Addition is a binary (takes two arguments) operator, and
needs a left term and a right term.
By declaring the operator + function to be a member of the Array class, you are implicitly defining it to take an Array object as the left argument.
There's another way to successfully declare this operator:
friend Array operator+(const Array &a, const Array &b)
Do you see why it works?
On this project, the biggest problem far and away was the division/modulo operators. Only four students implemented division correctly. (Of course, these are the 13's.)
Please go over your lab and program grades, and make sure that everything is correct. Good luck on your finals and have a nice summer.