CSC148 Marth 30th 2015

In this slog, I will be reviewing my earlier slogs on recursion, as well as how my impression has changed.  When I was first introduced to recursion, and practiced implementing recursive functions on tree structures, I felt like I knew how the concept worked, but trying to put all the pieces together to form a function was still difficult.  At that time, what I did was basically copy the format of examples provided during lectures, and making small modifications so that they would work for the lab problems.  However, most of the time I was really just guessing and checking, and even when I managed to solve the problem, I didn't really understand how or why.  That strategy worked until I encountered problems that required me to add in new things, such as multiple if statements in the recursive step.  I think my moment of clarity came as I worked on assignment 2.  I spent 2 days staring at diagrams of trees of gamestate, trying to figure out the link between each of the nodes, how to get from the root to the leaves, etc.  I ended up writing 3 separate functions, and then trying to put them all together in my attempt at a recursive function.  After reading the assignment sheet again, I started to look at the problem from another approach.  Instead of looking at the entire tree, I decided to only looked at the root and its children.  Doing this allowed me to figure out the base case of minimax, because each children is also a leave.  Then, I added children to the leaves of the original tree, and looked at the relationship between the root and its children, as well as the children and the grandchildren.  This is how I figured out the recursive step, and what helped the most was the realization that whatever the root asks its children, the children will ask the grandchildren.  This simplified by though process A LOT, as I only needed to think about one relation, instead of trying to think about all the possible interactions between every node in the tree.

I also read a few of my peer's slogs, notably Ken's at "http://slogfor148.blogspot.ca/".  Ken's post about recursion gave me a new perspective on how one can approach recursive problems.  Ken wrote that when he encounters a problem, he usually thinks about various code that can be possible solutions, while I tend to first try to figure out what sort of computations a human would do to solve a problem, and then translate that process into code.  Thinking directly in code definitely has its benefits, as there are many shortcuts and functions that can compress the steps that a human mind might take.  Another very important lesson that I learned from his post is how he analysis the data structure of the problem, and how his solutions can be generalized to work with difference scenarios using the same data structure.  This way of thinking will cover any potential holes or bugs that the code might encounter on different objects of the same data structure.