Week 6 (Extended)-Test Studying, Trees

*Since my class lecture time is on the Wednesday nights-this weeks (or rather last weeks) blog post is slightly late. I will be doing another post by next Wednesday in time for my next lecture. My apologies!

For this weeks blog post, I will be discussing two main things-my approach to learning how "trees" work, as well as my approach-and opinions on the test #1 that just occurred last night. On to trees. python trees, not unsurprisingly are quite dissimilar to actual trees-the only similarity between these two are  their "basic" components; leafs, nodes (branches), roots. Because python is not a graphic program, its impossible to actually draw trees-instead python uses their implementation of "lists" and nests a list, depending on how far down the path of the root to the leafs of a trees this list is. This was an extraordinary technique, because using recursion, you could in a sense-cycle down through the tree, into the "subtrees" till you reach your base case - a leaf that contains a piece of data. My one struggle with this idea, is the code we used to implement the tree, makes conceptual sense-although I still have trouble understanding the concept of a linked list (which was evident by my struggles in lab #6)

I also completed my first test yesterday! In 108, I always felt that the tests were a components of the course I struggled with-luckily I figured out my flaws, and better ways to study. In order to study-I made sure I knew my notes in depth, knew the important data structures and most importantly, understood how to trace all these new coding techniques. When it came to the test, I felt I did well-although I did make some mistakes I shouldn't have. For the first question, I felt the recursive tracing went fairly well, although it took me a while to understand at first, so I was unable to finish the last two calls in time to finish it. The second question, was similar to E2a, a very basic function to raise errors if certain conditions were met. The third question, also was quite similar to the lecture notes, a basic implementation of __contains__ that I had luckily included on my cheat sheet. The very last question, was a stack implementation that was a base class, that I understood-but unfortunately forgot that sum() doesn't work on a new ADT-I had tried to use the technique to create a temp stack, but couldn't quite figure out how to record the values in the stack. Overall, a decent result but I could be doing better.

Yet again, I would like to highlight the important posts my classmates have made in this course, firstly a post by http://achievementsuperlog.blogspot.ca/ on "Trees eh". He touched upon a very important concept of a tree, known as "traversal", which is how to move from leaf to leaf. In class we learned various techniques (post,pre etc order) in order to accomplish this, and reading his post, gave me the reminder to review those techniques myself.

Another important post I would like to draw attention to is http://aheapofpythons.wordpress.com/ on "Trees" again. This post discussed how we had actually been exposed to trees in lab #5-something that even I hadn't realized myself, since in the last lab, we essentially had a tree, we were recursively traversing to see if a number existed in it (sort of like the __contains__ method).

Thats all for now! Back to studying for my other midterms!

Week 5

Once again sorry for my late post! I've been busy working away on my TOAH model and the solution to the 4 stool problem-pretty much addicted to cheese at this point-but its now finally done!

For this weeks blog, I will be discussing to main things; a recap on recursion, as well as a look inside my own problem solving process for A1, which is due very soon. Firstly-recursion.

Recursion, at first seemed to me like a very similar concept to "loops" with for and while loops, doing something over and over again until a certain condition has been met, however after completing lab #4, and going through all the recursion exercises they gave, I finally completely understand this technique. In particular, solving the backwards writing exercise, really helped to solidify my understanding of the base case, and how recursion uses the base case, and then "minimizes" it a bit in unique ways, in order to properly go through the recursive procedure, and keep going until a certain condition has been met.

The other important project, that I was at hard with work this week, was A1. A1 without sounding too overly dramatic-was probably one of the toughest assignments I have had to do in university. Each step, tested my dexterity and ingenuity in python, and required me to know the topics covered in the assignment, like the back off my hand. By the end of the assignment, I finally understood recursion, and how to go "up and down" the recursion tree, how to construct the proper classes, and the right syntax to use in all these situations. One of the trickier parts of the assignment for me was, definitely my implementation of the ConsoleController. I initially had a lot of difficulty with this step, as I was unsure as how to call the proper methods, and use the right implementation of actually asking the player to input moves. After some thinking with my partner, we ended up deciding to let the player input moves, like a tuple- in order to select destination and origin stools for cheese-and raise an illegal move error whenever it was needed to do so.

For this weeks blog post, I would again like to highlight two other blog posts, that I found to be particularly compelling.

 Firstly, the most recent blog post by http://albertcalzarettocs.blogspot.ca/. In his post, Albert describes his difficulty with tracing the recursion tree up and down for the final step of A1-a problem me and partner faced as well. One piece of advice I could try to offer him, would be too always start with the base case (3 stools) and then see how to extend that case in the most simplistic way possible. That method worked for my partner and I, although it did take a inordinate amount of time to solve the problem in the send.

Secondly, I would like to highlight the most recent post by http://bounce14.wordpress.com/, where the author of the blog discusses the use of tracing recursion. This again relates both to the other post I commented on above, but also relates to A1. In his post, he describes his method to trace these functions, and suggests using a python visualizer in order to trace these steps-something I may start using in the future, to solidify my understanding of this topic.

That's all for now!
Thanks.

Week 4

Sorry for the delay all! Been away all weekend at a debate tournament with no wifi, so I was unable to update my blog in time.

This week I will be talking about "exceptions" and when to "expect" them (some funny python humour). Exceptions are something I was very familiar with in python-due to the amount of syntax errors I have made in the past. Exceptions are something to are in a sense "ingrained" in the programming language of python-but they only appear when you make a mistake, or do something to PYTHON considers is invalid to run your code. That begs the question though-what happens when you wish to call exceptions yourself, even if Python believes your code is valid in terms of its syntax and how it runs? This is where the idea of hard coding in exceptions comes from. To code an exception, we use our knowledge from OOP, and code them as a class, and inherit them from other exceptions. By this I mean if we were to hard code in some exceptions, we would inherit our new class exceptions from other ones, such as the general python "Exception".

Over the past week, I have had some experience dealing with exceptions, and understanding how they work. The lab this week really emphasized my understanding of this topic, as I was able to, through coding the "travel_to_new_pos" function, understand when and how the exception the needed to be raised in certain instances. Furthermore, throughout this lab- I was able to understand the exceptions even more, when it came to implementing the NotImplementedError, which I realized is extremely helpful, when we have method calls in 2 different classes, and we wish to show that we can't seamlessly merge them together.

For my blog this week, I would like to call to attention, to two different blogs, and comment upon them.

Firstly- http://alexcsc148slog.blogspot.ca/. In it, he said he had trouble with figuring out the solution to the second lab, for shifting the list, without increasing the complexity of the overall program. As a hint to offer him, I would suggest he consider looking at the list with "nodes", and looking up the concept of a linked list-where the first and the last members of a list are what is remembered and stored by the computer. I am sure he will get it in due time.

Secondly, I wish to comment upon the blog http://csc148mn.blogspot.ca/. In it, he describes (in my opinion), the fantastic learning method, and steps he took to understand exceptions, and how the try/except clauses work, when you look for exceptions in your code. I really enjoyed his post, since he talked about a lot of the main issues I faced, when learning this concept myself.

That's all for now!