An Attempt to Describe the Indescribable (Week 7)

Hello fellow recursion-beginners!

This post is my attempt to summarize recursion. Bear in mind that my grasp on the concept is weak, having had only a few weeks to wrap my head around what is undoubtedly a complex and mind-bending concept. It requires, I think, a little bit of trust in the computer that it will be able to follow the logic behind the code even though you don't really know the specifics of how it does so.

Before I begin, I would like to state that my definitions and explanations may not be entirely correct, as their main purpose is to describe the phenomenon of recursion, not necessarily to provide accurate definitions and explanations. In other words, I intend to be more colloquial than I probably ought to be.

So as I see it, recursion is the phenomenon of calling a function within its own code in order to avoid repetitive code and allow for deeper functions that do not rely on repeated for loops or unnecessarily long code. An example of a useful instance of recursive code is when dealing with class Tree- a sueful structure for several reasons, and unfortuneately requiring quite a bit of recusion.

Recursive functions require a base case. That is to say, the simplest situation in which no recursion is necessary. Often, this base case will be implemented frequently, at the end of every recursive call, so be careful when choosing both its condition and its code. Recursion base case looks like the following:

def count_nodes(tree):
    if tree.children == []:
        return 1

The code under the else clause will be the recusrive code. What we've learned so far is that there should be another function that is used to keep track of the information gathered in all the recursion calls. So in this example, if we are attempting to count the number of nodes in a tree, the else clause would look like the following:

    else:
        return 1 + sum([count_nodes(x) for x in tree.children])

What will happen here is that if the node that we've entered had no children, the function would return 1 for 1 node, the parent node. Otherwise, it returns 1 and then goes through each child node to check if it to has a child, until finally it hits a leaf node without children at which point it will move on to the next child node. This process goes on until every node has been hit and somewhat magically, all those 'return 1' gets added together and returned.

There is an element of trust required with recursion functions. I'm not quite sure how all those 1's were stored without a variable but I do know that it works. So I trust in it and I move on. Perhaps not the smartest thing, but it's working for me for the time being.

So this has been my summary or recursion. Hopefully I can come back to this post after a few weeks and have a lot more to say about recursion.

This has been an attempt to describe the indescribable.

Thanks and talk to you next week!
- Anisha Rohra

Recursion, Retracing, and Regret (Week 5)

Hello fellow recursion-ists!

I'm going to be upfront about something here- I didn't go to class last week.

*Gasp!*

I know, I know. This was a bad bad idea, because of course, we learned something quite important last week and I unfortunately had to teach myself how to trace recursions. I'm afraid to say I wasn't very successful at it, because the concept still confuses me a bit.

What I'm most struck by with recursion is that there is something intuitively that feels wrong with referencing a method in its own definition- it feels like it should create an infinite loop. It took quite a bit of extremely outlined tracing before I understood why it didn't create an infinite loop- the if/else clause that breaks the loop when such a thing becomes necessary.

What I'm still a little struck by is why the professor seems to prefer recursion to the longer, but more straightforward, way of coding these programs. I think it'll take a while before I accept that this is better way to do things. But I think I do agree that it opens a world of possibilities.

Also, I'm wondering about the confining base case method of approaching recursion. Can we use recursion without a base case? How about in a for loop? How would that work? Wouldn't the 'return' statement in the base case cause the loop to remain unfinished?

In short, I am left with many questions about recursion and remain apprehensive about its worth- especially considering how confusing I find it.

((Also I will not be skipping any classes any time soon!))

So long, and thanks for all the fish!
- Anisha Rohra

So Far, So Good (Week 4)

Hello fellow CSC148 monthers!

That's right, it's been an entire month in this course, and my emotions can only be summed up with "so far, so good". I hope that this post doesn't jinx all that.

Assignment 1 was much more difficult than anything we'd done in CSC108, but I'm slowly discovering that the best thing about more difficult assignments in the sheer sense of relief and exuberance that comes when you finally get it! It's unlike anything I've felt before, because that just doesn't happen when you finish an English essay or write a math test. And while getting a good mark can instill a sense of pride, it's never quite as reliving and uplifting as finally getting the code that you've been working on for perhaps hours.

On the other hand, studying for this test has not been fun. I will never understand why it is necessary to write code by hand. Yes, programmers shouldn't rely on testing methods for simple code, but it is my opinion that by asking us to write out code, you're limiting the kinds of questions you can ask us, and ultimately failing to get a full grasp on the kind of programmers we are. In fact, I cannot wait until the assignments are such that there are multiple ways to approach them and thus the code can be a lot more individualized (in short, I'm looking for more freedom).

Well, coming back from that tangent, so far, things have been going really well. I'm anxious though, because I know it's only going to get tougher from here.

Talk to you later!
- Anisha Rohra