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.