Week 7 - Recursion recursion recursion...

Recursion is about to become trickier. Previously, we've used to search through nested lists and trees to find the longest branch, to sum all of the values, and to return the values of the leaves. So far our assignments have dealt with relatively small trees, only 3 or 4 nodes deep. Assignment 2 won't be so easy. Why? Because tippy can take 9 moves to end and has 138 different terminal positions. That means that the algorithm we make to search through these game states and evaluate the best ones will take a while to search through. Furthermore, we'll have to use come up with a base case that checks if a player has won the game, and then quits searching down that tree. If we don't make sure to stop recursively searching after a player has won, there would be a total of 326,800 different games that could occur (according to wikipedia). It will be crucial to write a tight recursive algorithm.

Week 6 - Trees!

Trees are tricky. They work based on the recursive techniques we've been learning for the past couple of weeks. These techniques served us well for nested objects like lists of lists. So it makes sense that they work for trees, which you are kind of like trees of trees. One new thing we learned that seems to be specific to trees is that we always define the base case to be a leaf (a tree with no children). This case seemed to be present in every module function we wrote for lab 5.

The one thing I still have trouble with is the a if b else c. I can't always predict it's syntax. Whenever it's inside a list comprehension, I don't seem to need the else. When it's anywhere else, however, it needs the "else" at the end. I'm not always sure what to put as the result however.

Anywho, another week, another opportunity for learning!

Week 5 - Thoughts on Object-Oriented Programming

The language we have studied so far in CSC108 and CSC148 has been Python, an object-oriented programming language. While Python is a pretty straightforward language compared to Javascript or any of the C languages, Assignment 1 showed me that it's not always easy to think in terms of object-oriented programming.

For example, it was a bit daunting to create a parent class, such as game state, that could be general enough to support different kinds of future subclass game states. As developers, we don't really know what those new child classes or games will look like. What if my future games support more than two players? What if I want to implement a game that can end in a draw, like Tic Tac Toe? Partly because of these concerns, I was confused with how to implement my parent and child classes in Assignment 1. Sometimes I would put the SubstractSquare code in the the general class, and just call that from the subclass. What I should've done was raise a NotImplementedError if anyone tried to use the general class, and then override those methods with the SubtractSquare code in my subclasses. This was the implementation I used for Lab #4, and it worked well. Hopefully I'll remember to override parent classes when necessary in the future.