Week 4: More recursion

I have been meaning to post an update for the materials covered in week 4, but due to numerous exams and assignments that, with my unfortunate luck, crammed all into the period of a single week, this post has been a few days overdue. With that said, time to move on to the topics of week 4!

In this week's CS lecture ("or technically, 'last' week), we went over the topic of recursion once more. Though I personally have a relatively strong grasp on the subject, (due primarily to the fact that I find recursion to be a very elegant way of solving problems, complemented by the fact that I find it to make sense intuitively-speaking) I thought it was nice that we covered some more ground on recursion. On a side note, I found that many of my classmates find the topic of recursion to be somewhat confusing, and that they would use simplifying statements such as "recursion is just a method that calls itself" to describe it, which although is correct, does not necessarily reflect the other facets that makes recursion an elegant solution to solving programming problems (i.e. the concept of breaking a problem down into sub-problems until a base-case solution is reached).

We also covered some ground on the basics of tracing a function, which I think is rather important (as many other programmers would probably agree) in understanding how one's function is supposed to behave and how it behaves in actuality. Before I begin coding any functions in my module, I always have a quick mental side note with myself to quickly run the function in my head to see how I expect my function to be implemented, which I would then compare to how it is actually implemented when I run the module by looking at the results. I find that by quickly mentally tracing the implementation of my function in my head, I become more aware of any potential errors in my code when my program (inevitably) runs into problems during my first trial run. By tracing the implementation of my function, I find myself more "synchronized" with my code, for the lack of a better word, and am able to better understand what my code is doing in my program.

While I'm on this topic, one thing I found to have been particularly useful in my programming endeavours is including a print() statement at the end of functions that I feel "uneasy" about to more clearly see what my program is doing. This little "technique" has been very useful for me when I'm fixing my code due to unexpected errors.

We also briefly went over nameless functions with lambda during lecture. I found the concept to make sense intuitively, and I can easily visualize its practical applications when programming (i.e. reducing time spent creating simple functions that are only used once, as well as reducing the lines of code in a module). However, I must admit that the syntax for creating lambda functions still troubles me in my sleep, as I am very much unfamiliar with the syntax used in creating lambda functions. One of my goals in the next couple weeks is to become more familiar with creating lambda functions, such that I can easily integrate such functions into my code without fear of unexpectedly running into problems due to simple SyntaxErrors.