Bit late but oh well, last week was rather crazy.
Assignment 1 is slain, and a mild repose has been won through Reading Week. Let's catch up, shall we?
The assignment wound up going much more smoothly than predicted. In 108, we had assignments that would paralyze us for hours with no navigable solution in sight. Now, it's a bit more clearly - something I think is in part thanks to classes.
As far as assignments go, A1 was actually pretty intimidating: making a functioning game?! We did that with the word-search in 108, but most of that was already written: here, all we really got pre-built were a few controllers for storing the sequences of moves and the graphical interface that wasn't even necessary to submit, since we would make a console interface anyway.
But lo and behold, it came together. Perhaps the worst moment was, after deliberating on the fastest possible recursion formula for hours, we looked through the handout again and saw that the formula was given to us. Ouch.
Nonetheless, that final part was by far the most interesting, since it required a fair amount of brain-work to complete. We did ours in three parts:
1. Finding the best i-value to solve for four stools. A somewhat ugly "best_min" function was made to calculate the ideal i by just running the formula and taking the best result. With that information, which was reinstituted for varying stacks of cheeses, we could proceed to
2. A four-stool function. Looking at the given recursive function, it worked in three steps:
a. Move n - i cheeses to a middle stool and stack them up.
b. Move the i remaining cheeses to the destination stool using the remaining three stools (since the remaining i cheeses were the biggest ones).
c. Move the old n - i cheeses to the destination.
This required a small bit of brain work, but Dustin's formula that he showed in class for three stools helped us deliberate on how to complete the work.
3. The three stool function, as shown by Dustin in class, for the middle step (2b).
That was the assignment. The other subject examined was related to the week's lab, which took on some fun and funky trees. I must say, the language can be a little defamiliarizing at first, but the diagrams are a godsend in computer science. I find it so helpful to see how our information is relating to one another, and trees themselves are very much built on creating that sort of diagram-form. It would be fun to develop a graphical interface to display that kind of information neatly.
The one thing I still need to wrangle before the midterm shall have to be linked lists, which seem straightforward enough (I can reason the idea of a "head" and a "rest") but shall require more review before they become entirely clear. As well, looking over old midterms I find my mathematical brain is getting a bit dusty - complexity requires due review to deliberate how complex a code is (i.e. how many operations needed in worst-case scenarios, with all these simple O(log n) and such algorithms.
Wednesday, February 19, 2014
Saturday, February 8, 2014
A-cheese-ment
The profs have a sense of humour. That's good. It's a necessary tool in life, in my opinion.
This was an amusing week. Busy and enlightening, too.
More recursion was on the plate for the lab, and our instructor suggested we "trace" our code as we went. Basically, take down the simplest form and then add levels of complexity. Such brilliance.
It may not work for everyone, but tracing works fantastically for me. Seeing how the code is "built" has always been helpful (I'm a visual learner, as humankind likes to compartmentalize nowadays), but actually going through from simple to complex is brilliant. It made such a difference when puzzling out the code (lo, we did puzzle out that code!)
The pain of computer science often lies in the discovery of the tiny error that made you waste half an hour when all it required was more care. I used to make mistakes like that in math class, where one small problem (forgot to change the sign when moving something over, usually) made me burn in hell for eternity.
We had that sort of thing during the lab. Thankfully, it was resolved before we called it a night, but still, not fun.
In other news, I appreciated the experience of sitting front and centre in lecture - it is great for paying attention. And A1 is surprisingly easy once you parse all the pieces out and make sense of it all.
Ultimately, 'twas a week of good cheer and good learning. I understand all the more the value of being a careful programmer and working with visual aids. It doesn't require a full map of every assignment and value, but just drawing out what you're trying to do is a huge help.
This was an amusing week. Busy and enlightening, too.
More recursion was on the plate for the lab, and our instructor suggested we "trace" our code as we went. Basically, take down the simplest form and then add levels of complexity. Such brilliance.
It may not work for everyone, but tracing works fantastically for me. Seeing how the code is "built" has always been helpful (I'm a visual learner, as humankind likes to compartmentalize nowadays), but actually going through from simple to complex is brilliant. It made such a difference when puzzling out the code (lo, we did puzzle out that code!)
The pain of computer science often lies in the discovery of the tiny error that made you waste half an hour when all it required was more care. I used to make mistakes like that in math class, where one small problem (forgot to change the sign when moving something over, usually) made me burn in hell for eternity.
We had that sort of thing during the lab. Thankfully, it was resolved before we called it a night, but still, not fun.
In other news, I appreciated the experience of sitting front and centre in lecture - it is great for paying attention. And A1 is surprisingly easy once you parse all the pieces out and make sense of it all.
Ultimately, 'twas a week of good cheer and good learning. I understand all the more the value of being a careful programmer and working with visual aids. It doesn't require a full map of every assignment and value, but just drawing out what you're trying to do is a huge help.
Sunday, February 2, 2014
The Topic of this Post is "The Topic of this Post is 'The Topic of this Post is "'The Topic of this Post is...
Recursion may not be this week's official topic of choice, but it's a topic of discussion nonetheless, and a very intriguing one at that.
Recursion as a concept is not completely novel: I am also encountering it in Linguistics, which provides a sort of "compass" to how I should navigate the notions (or n-oceans) of recursion.
In a more CS-way, however, recursion is another example of obviously helpful computer logic. To go back to linguistics, recursion occurs when you embed a clause inside another ("when you embed a clause inside another" is an example of language recursion). Recursive humour occurs in the post title, or when I tell you that "to understand recursion, you must understand recursion."
If I want to write a program to track recursion in a string, I could write sentences into a list. For instance:
"Alice looked out from the window, where she watched the birds that ate worms in the yard, and waited for the mailman who came down the road each morning when it wasn't raining."
If I make lists within lists to show the embedded clauses:
['Alice looked out from the window,', ['where she watched the birds', ['that ate worms in the yard,']] 'and waited for the mailman', ['who came down the road each morning', ['when it wasn't raining.']]]
A program which did this would obviously need to be pretty complex. In the example, we can see that we would need it to end the current clause each time a preposition ("where", "that", "who", "when") appears, find some way to distinguish conjunctions ("and") as linking to a different clause, and ending a clause when punctuation or a preposition or a conjunction (sometimes) is encountered. Pretty complicated, but if we say that we can divide it up properly already, then all that is needed is for the program to check if there is a preposition introducing a clause, in which case, it calls itself recursively a creates a smaller list within the list. Otherwise, it encloses the current clause and moves on.
Of course, we discussed other uses for recursion in class that were more simple: using it to create "treebursts" with the Turtle program, or removing 3s from a nested list.
The treebursts were amusing to fiddle with: changing the level caused the recursion to go deeper, and at one point I was able to make the function create a large hexagon made up of smaller hexagons and triangles by fiddling with the number and length of the branches (although colour had to be disabled as there were only three colours given originally). The program was nonetheless very good at literally illustrating the use of recursion, which I now can see coming in handy in the looming assignment 1 (we discussed the formula briefly in class, which only served at first to bring back dark memories of examining the continuity of graphs in math class).
Removing 3s was a simple example as well, but still powerful, although the main thing I took away was the use of "continue" to keep the while loop moving.
The course feels more organized all the same. I still occasionally feel a bit daunted when staring at a new exercise, but the lab-work is always a great aid in providing relief in that regard. I couldn't help but feel a sense of achievement when the class Vehicle code we worked on in our lab was mirrored on the prof's screen in class.
The one last thing I have been really noticing is how much everytime I interact with technology, I envision the code underneath. While watching someone play solitaire, I imagine how the computer stores and displays the information (a list could hold the cards randomly assigned to each line, and another list holds the remaining deck; rules govern whether cards can be moved from a list to another based on stored variables). I look forward to a chance to see how we create the graphical interfaces used by programs in future CS courses. For now, I can simply ponder the code behind it all.
Recursion as a concept is not completely novel: I am also encountering it in Linguistics, which provides a sort of "compass" to how I should navigate the notions (or n-oceans) of recursion.
In a more CS-way, however, recursion is another example of obviously helpful computer logic. To go back to linguistics, recursion occurs when you embed a clause inside another ("when you embed a clause inside another" is an example of language recursion). Recursive humour occurs in the post title, or when I tell you that "to understand recursion, you must understand recursion."
If I want to write a program to track recursion in a string, I could write sentences into a list. For instance:
"Alice looked out from the window, where she watched the birds that ate worms in the yard, and waited for the mailman who came down the road each morning when it wasn't raining."
If I make lists within lists to show the embedded clauses:
['Alice looked out from the window,', ['where she watched the birds', ['that ate worms in the yard,']] 'and waited for the mailman', ['who came down the road each morning', ['when it wasn't raining.']]]
A program which did this would obviously need to be pretty complex. In the example, we can see that we would need it to end the current clause each time a preposition ("where", "that", "who", "when") appears, find some way to distinguish conjunctions ("and") as linking to a different clause, and ending a clause when punctuation or a preposition or a conjunction (sometimes) is encountered. Pretty complicated, but if we say that we can divide it up properly already, then all that is needed is for the program to check if there is a preposition introducing a clause, in which case, it calls itself recursively a creates a smaller list within the list. Otherwise, it encloses the current clause and moves on.
Of course, we discussed other uses for recursion in class that were more simple: using it to create "treebursts" with the Turtle program, or removing 3s from a nested list.
The treebursts were amusing to fiddle with: changing the level caused the recursion to go deeper, and at one point I was able to make the function create a large hexagon made up of smaller hexagons and triangles by fiddling with the number and length of the branches (although colour had to be disabled as there were only three colours given originally). The program was nonetheless very good at literally illustrating the use of recursion, which I now can see coming in handy in the looming assignment 1 (we discussed the formula briefly in class, which only served at first to bring back dark memories of examining the continuity of graphs in math class).
Removing 3s was a simple example as well, but still powerful, although the main thing I took away was the use of "continue" to keep the while loop moving.
The course feels more organized all the same. I still occasionally feel a bit daunted when staring at a new exercise, but the lab-work is always a great aid in providing relief in that regard. I couldn't help but feel a sense of achievement when the class Vehicle code we worked on in our lab was mirrored on the prof's screen in class.
The one last thing I have been really noticing is how much everytime I interact with technology, I envision the code underneath. While watching someone play solitaire, I imagine how the computer stores and displays the information (a list could hold the cards randomly assigned to each line, and another list holds the remaining deck; rules govern whether cards can be moved from a list to another based on stored variables). I look forward to a chance to see how we create the graphical interfaces used by programs in future CS courses. For now, I can simply ponder the code behind it all.
Subscribe to:
Posts (Atom)