A Recurring Theme

Back when I was a lit student (which was longer ago than I care to think it was),  I read far too many novels far too closely, looking for the most tenuous connections to what a professor or reviewer had identified for me as "the theme" of the book.

On one memorable occasion, my class read a novel that my professor presented as "a commentary on the struggle between art and science; between 'people of letter' and 'people of numbers'". Being a novel (and therefore presumably written by a 'person of letters'), the commentary was SLIGHTLY biased, and more or less decried scientists as immoral beings who are going to destroy the world as we know it.








I struggled with that book a lot, both because I hated that it seemed impossible to be both a 'person of letters' and a 'person of numbers'. I thought I was both, studying chemistry and English literature as I was, and if I had to choose, I wanted to be a 'person of numbers'. Unfortunately, working with letters has always been second nature to me, and working with numbers has always been much, much harder.

As much as I try not to believe in right brain/left brain and other dichotomies about learning styles that I (ashamedly admittedly) view as 'excuses' or 'not trying hard enough',  I've always thought that I just don't have a math brain. I love math, I work really hard at it, but I can rarely look at a problem and instinctively know how to begin solving it.

Frankly, if it weren't for years of teachers forcing me to complete math and chemistry and physics problems using the full problem solving method (which has a name or acronym that I've now forgotten), wherein you identify all the variables, and then go through the list of equations you know and see which ones use those variables, and then which of those equations provides the sort of variable you want as an answer, I would still have no idea how to solve most of the math problems in my everyday life.

So, I think it's pretty clear that a recurring theme in my life involves the struggle of dealing with numbers and conceptual programs involving calculations that comes with being a 'person of letters' in some sense trying to 'fake it' as a 'person of numbers'.

This struggle has reared its ugly head again in the process of learning about recursion for this class.  I feel like recursion itself has been a recurring theme of the lectures since day one, and my confusion with it has been a recurring theme for almost as long.

Looking through my notes, the first two sections on recursion don't really explain what it is or why it's important. They show how to construct at recursive function sum_list using list comprehensions, and although I can grasp that it's supposed to be more efficient than using a for or while loop, I don't really understand how that efficiency is accomplished. What confuses me even more, though, is how you seem to be able to call sum_list within its own body of code. How on earth do you use a function that you're still in the middle of defining?

Next section: "To understand recursion, trace from simple to complex", followed by some more example calls on sum_list. I traced them. Great, now I understand how to use this recursive function, but I still don't know how to write one (This is something I struggled with a lot in the labs---getting a handout that showed the recursive solution for a problem, then asking me to solve the same problem using a simpler loop. How was I ever going to learn to write recursive functions if I didn't get to try it in a supported learning environment? Wouldn't it make more sense to give us the loop solutions and ask us to condense them to recursive ones?)

One week later: Let's forget recursion and talk about exceptions for a while, mmmkay? (How about no.) However, in an aside with regard to assignment one, perhaps the most helpful definition of recursion I encountered in this class--"recursion is all about solving the problem of a given instance by reducing it to the solutions of smaller instances".

The following week, a traced example of the function remove3s blows my mind (and the mind of my fellow confused classmate, who had been puzzling over the same question as me for weeks--how do you call a function inside its own definition?) I feel like i get it now--the function call inside its own body is kind of like a reset button--it takes you back to the top of the code body, and you apply the same process to the smaller instance of the problem (e.g. the inner list in a nested list where the recursive function was first applied to the outer list). Still, I feel like I know how to use these functions now, but would be lost if I ever tried to write one.

The next week, a slide bearing the title "Getting that Recursive Insight for the Tower of Hanoi" strikes fear into my heart. "Insight" sounds a lot list "instinct", which is something I definitely don't have when it comes to recursion and by definition can't be taught. But then we go on to talk about identifying patterns--I can do that, albeit with some struggle--and I see that a function can be recursive and still have if/else statements and a function body longer than one line (at some point, I got in in my head that all recursive functions had to be in the form of list comprehensions, which where often paradoxically incomprehensible to me).

It wasn't until I started studying for the midterm and came across past tests containing problems that required recursive solutions that I realized two things:

1) I know more than I thought I did about recursion, and tracing function calls really does help you to understand how it works, even if it doesn't feel that way at the time.
2) "insight" !=  "instinct";  insight can be learned, and the best way to learn it is to keep doing the same sort of problems, over and over again. After A1 and two practice tests, I was able to pick out which problems in later tests sought recursive solutions, and (despite my earlier misgivings about lack of practice) WRITE THOSE SOLUTIONS.

Following the midterm, in hindsight (and in the course of writing this post), I have discovered a new recurring theme in my academic life--trust the process. Sometimes things you think aren't helping you or teaching you anything new are doing exactly that. Learning the pieces of things can be confusing, but the feeling you get when you're able to put those pieces together is incomparable and incredibly satisfying. (And obviously, gaining recursive insight into a problem is actually a lot like looking for a recurring theme in a novel. Just because I wasn't born a 'person of numbers' doesn't mean that I can't use the skills I do have as a 'person of letters' to solve numerical problems when they show up in front of me.)