This week, we focused on namespace, scopes, unit testing, and the notorious algorithm of "Tower of Hanoi". All in all, I did not have a problem with namespace, scopes, and unit testing as they are mostly very straight to the point. However, the recursions behind the Tower of Hanoi prove to be highly challenging. Tracing the first few steps is relatively easy but afterwards, the numbers just decide to explode all over the place. With the confirmation of the first few traces, I have to use what Professor Heap like to call ,"intuition", to believe that the recursion works. In terms of recursion, being able to believe it works really assist me into thinking ahead in any kind of programming questions.
With that being said, majority of the time spent this week was dedicated to finding the solution to Tower of Ann Hoy that uses four stools. Indeed, it was devastatingly hard because recursion prove to be so abstract inside my brain. Luckily, the handout made it easier by reminding us to split the algorithm in three parts, where first and last basically uses the same concept for 4 stools and the second is a complete copycat of the codes of three stools. I realized when it comes to recursion problems, my thinking becomes optimized when I use pencil and paper. The human brain is simply not a stack so we could only remember so much before we forget the rest. I traced the most simple number of cheeses I could think of and found a very common trait between the algorithm of four and three stools. Although my current codes are not optimal, I am really proud that I toughed it out and found an alternate solution.
It's great to see i'm not the only one with some difficulties in recursion! Tracing always makes it easier but honestly after a few recursive calls i'm way too impatient to continue. Anyways it's interesting how you found a solution without an optimum "n", did you hardcode a solution for a certain value? ex. I originally hardcoded moving all but 2 cheeses instead of one like in the example.
ReplyDelete