SLOG Post #2 - Tracing Recursive Functions

This week in class we learned about recursion. According to Wikipedia, a recursive definition is something that is "used to define an object in terms of itself". We were looking specifically at recursive functions, which are functions that call themselves in their own definition. These sorts of functions are very useful when working with arbitrarily-nested lists. For example, you can define recursive functions that can sum all of the numbers in an arbitrarily-nested list of integers with very few lines of code, while other methods would be difficult and involve relatively complex code.

Our lab this week focused on tracing recursive functions that took progressively more complex arguments. We were encouraged to not show every step, as the Python visualizer would, but instead build upon information that we had already confirmed. For example, if we already confirmed that the function worked on a non-nested list, we could use this information in later examples that involved nested lists (of varying degrees). I found this sort of work to be somewhat challenging. It was easy for me to determine how the function would work and guess the correct return value. However, showing how the function got to that value was a lot more difficult. I was often unsure of how many steps to show, because I was not able to identify which steps were most important. However, after looking at many examples and trying many practice questions, I think I've gotten pretty good at it.

The other major focus of this week was Assignment #1, which was due on Thursday. When I first looked at the assignment description sheet, I had no idea what the assignment was asking for or how to do it. However, after consulting Piazza and re-reading the notes from the lectures, my partner and I were able to get a general idea of what to do. We started off working on the GameState abstract class by thinking of attributes that all game states would share (such as whose turns it is, if the game is over, etc.). We then went on to create the SubtractSquareState subclass by filling in the areas that could not be covered by GameState. We went through a similar process with the abstract class Strategy and our strategy subclass RandomMoveStrategy (the strategy of randomly choosing one of the available legal moves). After we had finished these classes, we worked on class GameView, which was used to facilitate communication between the user and the game state and strategies. the game view took the longest to finish, as we often had to go back to GameState and Strategy and change things to make the overall program work better. We also had to be very careful with our style (in particular, our docstrings and examples). Even though we started the project a week in advance, we ended up working right up to the deadline (we submitted it at 9:45 pm!). I feel that the work with the numerous docstrings was quite tedious, although I understand why this kind of work is important. My overall impression of Assignment 1 is positive: I think we learned a lot about object-oriented programming and inheritance, and I also think that we did a pretty good job.