Program correctness

This week, the focus of you lectures have moved towards program correctness, which is more or less a formalization of proving that your code does what it should. I found this topic to actually be quite intuitive and something I had been doing in a much less rigorous and formal way in my head when planning my code. I also know have more of an appreciation for the somewhat draconionan rules we had for program style, most of which was directed towards making your code both readable and breaking it up into smaller parts. The idea of smaller blocks of code with helper function especially seems useful now since trying assess the correctness of a large block of text is far more daunting then the same code broken up into several parts. However, applying the proof methods we've learned to program correctness feels infinitely more tedious, with the attention to detail required being astronomically greater. I can't imagine how development teams would manage to be able to prove their code correct for a major project like an operating system. Unfortunately suspect that they don't, though I also suspect our computers would benefit greatly if the did.

Recursion and Unwinding

Having seemingly finished induction for now, though it will inveitably come up again I'm sure, we've know moved the focus of our lecture towards recursions and time complexity. Recursion was initially a bit of an odd concept to me in programing class. While I didn't have any exceptional difficulty understanding it and it's usefulness, it always seemed much more natural to accomplish the same goal with a series of While loops. However, after enough practice, I began to become more use to the idea of using recursions consistently, if for nothing else because of how it seemed to form a far more elegant solution to most problems. However, after finding closed forms for recursively defined functions in lecture, recursion seems far less elegant. It is somewhat suprising how we define closed forms for recursive functions, as the methods in many ways are rather unintuitive. 

After working on the weeks problem set, and getting stuck at a paticular step, I began to wonder how one would go about proving a closed form could not be found for a function. I would imagine that it's more likely that there are many functions for which we have not yet found the closed form for, rather then we know it is impossible to find a closed form and I for one believe the distinction is important. However, having tried to prove for myself that a function could not have a closed form, and, with Google yielding no useful results, I began to realize a certain failing in my knowledge of proving techniques. For most of the proofs we've done, i've had atleast some idea of the concepts and theorems behind what is necessary to provide insight into what we are proving. Yet, while proving that postage of 5 and 11 cents couldn't make postage of 19 seems black and white, proving that a function couldn't have a closed form is far less intuitive, almost to the point where it feels like i'm trying to prove a cat isn't a dog without knowing what a dog is.

The first term test

In general, I have found most university tests and exams to be soul crushing affairs that, taken collectively over the span of the year, constitutes a suite of hostile, spiteful acts against the test taker and humanity itself. Thus, this year I resolved to stay at least a week ahead of all my assignments and tests where possible and afford my self as much time possible. Surprisingly, the spread of quantifiable difference it has made between courses affords an incredible range of results, some much more positive then others.

I am pleased with how the first test went and found it it to be both fair and meaningful assesment of our ability to demonstrate and apply the knowledge we've learned in the class and am glad to see that my studying and effort thus far have paid off, both in terms of my confidence with material and with my enthusiam towards the course.