Course Wrapup: So long and thanks for all the fish

My interest in computer science stems from my time in high school where I took computer science courses with my good friends who did a lot to help me improve my coding and encouraged me to think through the problems I would encounter while coding. I enjoyed the subject so much that I decided to come to University for it. One of the unique things that this course provided me with was the opportunity to continue to work with others to help improve my understanding of the material. In most some subjects it can be painful to work with a partner but I find that computer science is one subject where it is much more difficult and stressful if you try and struggle through alone. Since the course requires so much dynamic thought in order to problem solve it is useful to have someone who you can share your ideas with or gather feedback from. Overall I thought that the group projects were an excellent help with my understanding of the material.

If there's one concept that still stumps me from time to time it's linked lists. Having worked with regular lists for so long its sometimes hard to remember exactly what the differences are and how they affect the function you are trying to create to solve a problem.

In conclusion, I really did enjoy this course and it has given me great faith going forward that computer science is indeed the field of study I want to be in.

Recursing my thoughts on Recursion

I chose to revisit my earlier SLOGs on recursion because I feel like recursion was perhaps the most central topic in the course. So with further ado, here's how I now view recursion now as opposed to then.

I feel as though this has been covered before...

 In my first post about recursion I used what I would now consider a somewhat simplistic cake metaphor to describe my initial thoughts on the subject. I quickly discredited that metaphor by stating my real view on recursion after I spent more time thinking about it. Now, as the course is coming to an end, I've had even more experience with recursion and it's time for me to re-evaluate my thoughts on the subject.

Recursion is a difficult concept to wrap your head around but, at the same time, is an incredibly important programming tool. Originally I looked at it as running an entirely new process, inside the original process (albeit the new process is exactly the same as the original, just with different values as input). Having had more experience I now see this as a definition that is very broad in scope. One of the main data types we worked with throughout the course in a data tree. We explored how to search through the tree and find the values we want to use. However, when you think of searching trees in terms of recursion you'll find that my definition is too broad to really cover what is happening. My definition says that you are running a value check inside a value check inside a value check, etc. However, what you are really doing with recursion is traversing the data structure. And while that may be a 2 dimensional way of looking at it as opposed to processes inside of processes, that is what it ultimately boils down to. With this in mind I now understand that the benefits of recursion need to be evaluated on a case to case basis. I've stopped looking at recursion as a static concept and started to integrate it with my problem solving. I don't think in terms of "I need to call recursion on this", instead I think "this is the data structure I am presented with and I need to access it in this manner". This way I am inherently aware of both the return type and recursion format required and have a much easier time finding the solution.

I think we're done with this topic... or are we?

Test week

There wasn't a lot of new material in class this week because of the second term test so instead of doing a review on new material I will just express my thoughts about the test. To begin with I thought that the questions were all fair and I felt as if I had a pretty good idea of how to solve them. I found that the most challenging question for me personally was the linked list question. Linked lists are require a very specific order of events when you are manipulating them. One mistake in that order of those events could disrupt the order of the entire list. I personally feel as though I should have done more review on linked list operations before the test because it is one of the things where you encounter a variety of different solutions depending on the task at hand and you can only learn how to solve them by practicing as many as possible.

Lamenting about Linked Lists

In week 8 of the course the focus was changed from trees to a new data structure in Python called a linked list. A linked list is similar to a normal python list in that it stores values in order and every value has a position that relates to the other values in the list. What differentiates between the two is how the values in the list can be manipulated.

While working with linked lists the focus is on manipulating from the front and back of the list. Because of how the list is connected it makes manipulations from the front/back much more efficient than if you were working with a regular list. However, if you were scanning for a certain object in the middle of the list it would be more advantageous to use a regular list.

An example of adding a node to a linked list, it makes two new connections if it is in the middle

Trees, trees, trees

Week 7 was the introduction to tree structures in python. More to the point we learned about a specific type of tree called a binary search tree. While a regular tree can contain as many branches as possible on any particular node, a binary node can only have up to two branches.

Search Tree

Binary Search Tree

Regular tree (just in case you were still confused)

One of the advantage of using a binary search tree is that calling an inorder recursive search function on the tree will return the values from lowest to highest. As Jeremy mentioned in his blog there are two other ways to recurse through a tree, preorder and postorder. He uses a letter system to describe the three orders which I find particularly helpful in understanding.

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.