Recursion Revisited: Back Down the Rabbit Hole

In my first review of recursion I discussed how I managed to wrap my head around the concept and how I was able to convince myself of the legitimacy behind the principle. However, that was just step one into the experience that is recursion. The next step is to take that knowledge and be able to apply it to actual problems, which is where the real fun begins.

Here we go again...

One of the important things that is used in most recursive applications is the creation of a base case which is a call on the function that completes without reaching the recursion stage. Getting the correct structure for your base case is important since it is what gathers the output for each stage of recursion. If you aren't careful with what you choose for the base case it might work for that one case but you may run into difficulties when you actually need to recurse.

OOP

Object Oriented Programming is one of the main things about Python that I find makes it much more user friendly. The pre-existing objects such as dictionaries and lists are well formatted and the ability to create your own object types is extremely helpful and allows for a much more dynamic range of applications.

You can assign the same functionality found in the built-in objects to your own objects. This includes the special __str__, __repr__ and __eq__ functions. In addition to this you can also assign any custom functions that would be helpful when manipulating or working with your objects.

I didn't really encounter any specific problems that gave me greater insight into object oriented programming but one of the more challenging aspects was creating the __str__ function for your custom object. I found it to be the most helpful part of understanding how your objects work because it forces you to think about what exactly you are attempting to represent.

Wrapping my head around recursion

I now know that recursion is when you call the method you are using inside of that method. It's a very useful technique that saves a lot of time and prevents a lot of repetitive coding.

So it's simple right? All you have to do is call method A inside of method A and then... wait a minute. How can I use method A inside of method A if I 'm not done with my original instance of method A? That would be like starting to eat a cake, finding the exact same cake inside of it, eating that inside cake but then finishing the outside cake... which happens to be the exact same cake as the one you just ate.

I can have my cake inside a cake and eat it too!

Or at least those were the first thoughts that went through my mind when I heard the definition of recursion (possibly excluding the cake metaphor). However, I soon learned that my mindset was on the wrong track.

A depiction of my train of thought at the time.

What I failed to realize at the start is that, if the method does not call it's recursion it returns an actual value. Therefore, when a method undergo's recursion it simply continues to narrow down the scope of the input until it eliminates the need to undergo further recursion. It then returns that value to previous instance of that method. It continues this process until it once again reaches the main instance of the method and can undergo no more recursions.

Despite the very logical explanation behind how recursion works I will continue to feel like a wizard every time I utilize it and so will Google employees when they're not too busy confusing web surfers with logic jokes.

Oh Google, you sly dog...

Subclass Sorcery

While I was already aware of classes before coming into the courses, the idea of subclasses was new to me. I had never really put any deep thought into the uses of classes but it makes sense that they would be used a templates for more specific classes (or rather subclasses).

When the topic was first brought up in class I was a bit confused as to how inheriting a class into another class was at all useful. Why bother creating a class that's just going to be part of a more specific and detailed class? Isn't that just making life more difficult?

I thought classes were for students...

 As the lecture developed I began to realize that making a main class to be inherited by subclasses isn't particularly useful when only using a single subclass such as the example. I had to expand the scope of my thought and consider that the lesson wasn't just about the particular example, but was intended to show how a subclass would inherit a class. The useful part of having a main class is when it gets inherited by multiple subclasses. It's a broad template that prevents you from having a ton of unneeded identical code scattered throughout your program. With this in mid it was easy for me to picture how classes would begin to form a branch-like structure where everything is connected to a mean trunk (or class) and it branches off into different subclasses which can continue to branch as needed. So instead of making a new tree every time you only need to add a branch to the one that's already there. It's classception!

So like a class... inside a class... inside a class...

Why Geeks Should Write

Writing is something that most of us take for granted on a daily basis. "Geeks" in particular may not get much practice on their formal writing skills because their field of interest or hobbies probably don't require them to exercise them to a great extent. Most geeks have the capacity (and/or patience) to write the same volume as someone who wouldn't be considered a geek but they would have a very different way of expressing their opinions in their writing.

The problem with this is that the geeks of our world come up with some of the most wonderful and innovative ideas. However, these ideas also tend to be expensive and time consuming which means that, in order for them to flourish, there needs to be some sort of external support. Whether it be asking the bank for a loan or explaining a complicated concept to a potential investor there needs to be a kind of communication that can be understood by people who don't think in such "geeky" terms.

It is definitely important to be able to verbally communicate your idea to someone else but most times those who offer you support will want written processes and documentation outlining how you plan on spending their resources to develop your great idea. Formal writing is very important in the world of business and despite how much we geeks would love to smack a folder of equations in front of them and smirk as they attempted to comprehend our obvious superiority it won't exactly land you in their "good books".

Like Santa's List but with more legal disclaimers

The geeks can't stay oblivious to the mysteries of writing forever. Our modern world simply won't allow it. So until one of us geeks comes up with a mind reading device I suggest we all gather up a pen and paper and get to work.