Tuesday, September 24, 2013

Tower of Hanoi

I started Assignment 1 today. Not that I didn't have more emergent work, I was just really curious about it.

Essentially, Assignment 1 is a Tower of Hanoi problem but using cheese and stools instead of rings and posts. The problem reminds me of a University of Waterloo CEMC contest question. The contest had a set number of posts (I believe it was 3) but could have rings varying from 1-4. Contest writers were asked to print out the number of moves needed to get all rings on one column given the number of rings and the beginning placement of the rings (could be on any of the rods, as long as stacked from largest to smallest). Anyway, it was hard. I couldn't finish the problem. I had a structure in place to print the correct output but I had no idea how many moves it would take. Of course, with the introduction of Assignment 1 I learn that there isn't a verified most-efficent method to solve a Tower of Hanoi problem. I'm not sure how Waterloo meant to verify I outputted the correct numbers...

So after an hour or so of work I am in the middle of Step 3. I thought I was done, tried to run the program but got an error. Apparently the name of the class I'm working on isn't defined *eyeroll* I'll take a fresh look later.

I really dislike filling in someone else's skeleton. Not only do I have to do things by their logic, all the parts are so interconnected I can't test as I go. I have to get a lot of code written before I can start to test (unless I want to edit things which could open a rabbit hole I'll never come out of). I prefer to write small bits and test as I go. In my opinion, it makes finding errors easier. Of course this could be considered 'guess and check' programming. I wonder how other people do it... A lot of people seemed to have trouble with Exercise 1 and the blackbox testing. I didn't find it an issue. I only need specific error messages when I'm doing complex structures. Then its time to break out the break points.

Monday, September 23, 2013

Welcome to the SLOG

This blog is a courSe bLOG for CSC148, 2013 Fall Semester at University of Toronto.

Of all my courses this semester, it was quite surprising that computer science was the only one that had a writing assignment. At first I thought it would be difficult, I'm a physical science major because it's easier for me to write it numbers and symbols than words.

Once I realized it was just keeping a blog I relaxed. Being marked on it raises a little anxiety, but I think it will be helpful to analyze myself as a programmer.

Why is a SLOG (the name still irks me) useful?

  • Forces me to distinguish what is actually learned
    • There isn't much of a need (for me) to take notes in comp. sci. classes, because I learn the syntax and commands best by implementhing them on my own to solve a problem. However, the different topics that I've actually learned can get lost. This forces me to pick them out and explain what I learned.
  • Writing a program doesn't leave much of a paper trail
    • If you write a program and make a mistake, you go back, change it, and then save over it. The mistakes you made are gone, either to be forgotten about or to occur again and again. A journal can be a document of errors that will stay (if you don't go back and delete yourself) even after you've corrected your program.
  • Creeping other people's progress
    • I think this is supposed to be called 'learning about other people's viewpoints of the course anonymously' but it feels like creeping to me. Still, it can be useful. One thing I realized quite recently is that university comp. sci. doesn't have any high school prerequisites. I've done most of the course content in Java so the course is learning a new language, not new concepts. The SLOGs could help me understand the other point of view.