Week 12: Last Impressions: Look Back Over the Course, Conceptual Hurdles, and Course Events

           Today was our last lecture of the semester. As we walked into lecture, we were asked to fill out a survey on our opinions on the various aspects of slog writing. Some of the questions on the survey were the following: Did we enjoy writing our slog? Did it help improve our writing skills? Did we benefit in terms of understanding course content by writing the slog? Although slogs were kind of annoying to write sometimes, it would be hard-pressing to not find someone who didn’t benefit from the slog experience. Slogs held me accountable for reviewing what we learned in the week prior so that I would have something to write about. It also kept my writing skills somewhat sharp, because if it wasn’t for this, then I would have gone my whole 1^st year without having had a single writing assignment. I also have a feeling that the instructor was implying something rather bold to the entire class when he assigned our first entry to be on “why geeks should write”. Because I wrote the slog, I can now look back at what we did this semester!

           The first phase of this course was on abstract data types and object-oriented programming. Honestly, these concepts were not that hard to grasp. My group from assignment 1 had a bit of a trouble applying the concepts of OOP into the assignment at first but we reacted to our hardship by keeping with the basics, like paying attention in class, reviewing class notes, and thinking about how the instructor came to the conclusions about his in-lecture examples. The end result was that we received a very satisfactory mark on the assignment and also satisfactory marks on our first tests.

           The content after the first test could have been a steeper learning curve but I now appreciate the instructor’s intent to ease us into recursion. We were first asked to trace recursion, which was easy to find outputs for as long as you were vigilant with reading the code. However, looking at the bigger picture now that we are at the end of the semester, I realize that the purpose of the exercises was to introduce us to the mechanics of recursive thinking. I addressed this issue and how I reacted to that in my previous slog. It was first very awkward shifting from using iterative loops until that point to not being able to use them at all. The point is, I got over my difficulties by practicing a lot and Binary Trees were just variants of Trees that I had no problem handling once I got over my “fear” of recursion and trees. Once our class finished covering Trees and Binary Trees, we went onto linked lists.

A major course, and school, event occurred around that time, for what amounted to be a month-long strike by the TAs in the university. Although I did fairly okay (not as well as on my first test), I believe I lacked the TAs help that I would have liked, such as asking clarifying questions about linked lists in the lab that we did not have, and going to the help centre about assignment 2. Since we did not have TAs to mark our assignments, we now have no idea how we did in assignment 2 going into the exam period (although we did get our second test back in a relatively timely fashion) as well as missed opportunities with lab quizzes to boost our marks. At the end of the day, it is up to me and my work ethics and skills to perform in his course, but the strike certainly did not make things easy. It was sometimes frustrating, to say the least.

After test 2, there were only two weeks left until the end of the course, so I would not say anything significant happened. In lectures, we learned about assert testing methods, some sorting algorithms that use recursion, and running time size. My reaction to the running time analysis was that it was rather similar to what I previously did in CSC165, so no difficulty there. They were concepts that were not too hard to grasp or required that much thinking or creativity. I will do the lab exercises in the coming future to practice them. The odd thing about our last assignment was that it did not cover any of the aforementioned concepts, but rather more complex tree traversal (i.e. recursion). It did require some outside-the-box thinking because the type contracts of the given functions were not ideal to solve the problems of the functions. There were additional information needed that the existing parameters did not have or there were additional information that could not be returned by the existing return type. For example, with game_lengths(), we needed to return a dictionary of all possible game lengths, the keys being the possible game lengths, and the values being the number of the occurrence of the particular game length. We used a recursive helper function to first compile a list of all the possible game lengths and the original function to compile and return the required dictionary using the list returned from the helper function. Overall, the assignment was not hard and I am confident we will get good mark on it.

Overall, I would rate the course as enjoyable. I overcame a big hurdle with recursion and learned a lot. It was the right amount of intellectual stimulation and learning. I now know for sure that Computer Science is what I want to study in university. Preparing for the final exam, I will keep it simple and practice, practice, practice. I also had the instructor from this course in CSC165 and he was awesome, introducing and explaining concepts well and assigning challenging assignments that are able to act as learning experiences. Thank you for reading my slog. Good luck to everyone on the exam.

           p.s. Shout out to Brendan (https://brendanhau.wordpress.com/) for writing an awesome slog. It looks like the strike affected him the way it did everyone else, but he is optimistic and trusts the returning TAs to provide support and mark all of our stuff in good time. I will adopt the same attitude! 

Week 11: Revisiting an Earlier Slog Posting

           For this entry, I decided to read my slog entry from week 5, which was my impression of tracing recursion. The first thing I noticed from reading it was how I did not necessarily understand why we even did recursion. My opinion on it was that it was a neat little trick and an alternative to using loops, which can get complex and long-winded at times. Of course with two weeks left in the semester, I now know that recursion is a powerful tool that is crucial for implementing various methods in trees, binary trees, and possibly for many of the other data structures out there.

           I appreciate the fact that the instructor first got us comfortable tracing recursion as a way of easing us into recursion and to allow us to understand the process of how it works. In my opinion, it got me to be good at tracing recursion, determining the output, and becoming comfortable enough to start writing recursive functions. I could tell by reading my writing that I was not fully engaged in the activities and did not take it seriously, only focusing on getting the right output instead of being cognizant about how the output was being generated with recursion. I really paid the price because if I had been more cognizant, I believe I would have had an easier time in the beginning when we got down to writing recursive functions ourselves. I did not even notice that every recursive functions had a base case (i.e. the smallest possible version of the original problem) and the general case, which breaks down the original problem. It took some hard work to recover and catch up. I guess in a way I agree with my past self in that the tracing was actually “the calm before the storm” of the actual implementation of recursion.

The lesson learned is to not just do things for the sake of finding the answers but think about the process as well in future courses. That is what learning is. I really do believe that I am solid with recursion now. Of course, there will be those curveball problems that will challenge me, but as long as I stay calm and remember my training from this course, I do not foresee any problems occurring. I reacted to my hardships by doing the lab exercises while understanding why the answers are the answers and reviewing notes from lectures. It all comes down to practice.

With this entry, I also decided to look at other people’s recursion-tracing experiences. Christopher (http://www.mybigfatcsc148slog.blogspot.ca/) and I shared similar experiences with tracing recursion. He too did not face many difficulties tracing and rather, found it to be simple, and appreciated the instructor getting us to practice tracing first. I liked how he thought recursion was not going to be “that bad” because that’s how I felt too. It looks like later on in his summary of recursion that he rather enjoys recursion, whereas I’m “cool” with it. I guess people differ in strengths and weaknesses. 

Week 10: My Impressions of Week 9

Week 9 was one of the more uneventful weeks in this course. Perhaps that was because we only had one hour of lecture and no lab due to the ongoing TA strike. The lone lecture was on more advanced binary search tree topics namely the insert and delete functions of the BST node. I felt like they were just an extension of the last few weeks’ lectures. It got me to review BSTs more thinking it would be on the test. While it did not have direct carryover into the test, we did come across a question with a BST that was of lower difficulty so it was a big help there.

           I would assess the difficulty of the test as fair. However, my experience was far from encouraging. After consulting with my classmates after the test on Wednesday, I realized that I made some critical mistakes right from the first question, which asked what the maximum height of a 20-node tree could be. The answer was 20 but a combination of fatigue and butterflies in my stomach caused me to mess up on that question. The BST question I got through no problem mostly because fortunately the answer was very similar to an example I had on my aid sheet. However, the last question concerned linked lists and that really tripped me up. I answered to the best of my abilities but having been introduced to the concepts a mere week earlier, I was not as solid as I would have liked to be. It takes me longer than most people to understand concepts sometimes. The combination of the lack of time and the stress caused self-doubt and confusion while attempting to answer the question. I think I got the general framework from referring to my aid sheet but I know I messed up somewhere. Overall, I was racing against time the entire test and I don’t expect the outcome to be anywhere near how I did in the first test, which I did well on.

           I learned I really need to shore up my understanding of linked lists and binary tree traversals before the final exam. I looked at the syllabus again recently and I noticed that the final exam is worth a whopping 40% of our course mark. Talk about high stakes. I could afford to make mistakes in the midterm because it will only be worth 6% at the end. I have to do everything in my power to make all the right moves when the final exam comes so I can end the school year with a bang and hopefully get into the program.

           For some inspiration, I again scrolled through some slogs. Like Christian from last week, Rod (http://rodcsc148.blogspot.ca/) has written a very nice slog this semester with illustrations and clear and precise explanation of concepts. His most compelling entry was his latest one about his impressions of week 9. He identified the importance of critical and deep thinking before actual coding and appreciated the instructor’s algorithmic approach to implementing the delete function of a BST node. In writing, he said he would take the same approach of the instructor and Rod, I shall do the same. Like me, he found the test to be more than fair, but seems to have experienced more success than I. He credits his success to doing the lab exercises in advance because he found the test questions to be variants of the lab questions. Rod, thank you for pointing that out and I will make sure to prioritize labs when studying. To anyone that actually reads my slog, I would definitely suggest Rod’s slog.

           I would really like to ask my fellow classmates to read my slog (I put quite a bit of thought and work into it) and leave comments. You will make me very happy if you do. I endeavor to do the same.

Week 9: My Impressions of Week 8

Amidst the frenzy of the strike and the mad dash to hand in our assignment, we learned what linked lists are, yet another type of data structure. The instructor described linked list structures as “objects (nodes) with a value and a reference to other similar objects”. I had no idea what he was talking about at first but then like I did in the past with object-oriented programming, I thought carefully about the name “linked lists”. From the term “linked”, I derived the fact that the elements within a linked list were “linked”, which I think means that each element is aware of the one succeeding it and can therefore manipulate it somehow. Unlike the Tree and Binary Tree classes, this data structure requires two classes, an “LLNode” class and a “LinkedList” class. The LLNode class represents the “node” to be an element in a linked list. It both keeps track of the data, which can be any object, of the current node and the next node, which could either be the same LLNode or None, if the current node is the last of the list. The class LinkedList is what is known as the “wrapper class” for the LLNode class. Wrapper classes are called what they are because they “wrap” a data type into an object for that class. In this case, the LinkedList class has LLNode objects as the “values” and keeps track of information about the entire list, including the front and the back of the list, and its size.

           While we used recursion to traverse through trees and binary trees, we only used iterative methods to work with linked lists. “Walking along” a linked list did not seem hard to me when the instructor explained it. However, when it came to changing the nodes’ values or deleting or adding nodes, it was definitely harder than doing that with any old regular python list, which you can just do with indexing and aliasing. For me, it was very confusing to keep track of what the next node was going to be after deleting or adding the node of interest in the middle of the linked list and then shifting the rest of the nodes forward or backward. Although the instructor did his best to explain the concepts behind it all, it was ultimately up to me to apply the tools he gave us. The lab was quite challenging and while it would have been nice to have TAs’ support, I failed to execute the exercises so I have no excuse for that. I certainly did pay for it by not performing well in the linked list portion of the test.

I am finally starting to understand how to work with trees and binary trees but this linked list was just another live grenade thrown into the fray. Sometimes I feel that this course is moving too fast. What I will do to address the issues is to follow the advice of the instructor, which is to draw diagrams when working on linked list exercises and spending extra time outside of class to review concepts introduced in class so that I am prepared to get right into applying the tools when it comes time to practice. Hopefully the next few weeks these concepts will come together for me and any others who might be struggling.

I took the time to look at a few slogs of my classmates this week and I must say my good friend Christian’s slog (http://christiangarciacsc148.blogspot.ca/) is quite good. You can tell even by skimming through his entries that he takes special care by attaching pictures, pasting special pieces of code that are of interest, and editing his writing to make them more readable, which is something I must work on. His explanations of concepts are very clear and concise. His latest entry was also on linked lists and while he and I are together in terms understanding the basic idea behind linked lists, he does seem more enthusiastic about learning more about them, which I admire. He also seems to care more about other people’s slogs, as I have mentioned them once before, which the good guy here makes sure to give a shout out to his classmates every week. I will fix that myself in the coming weeks. Overall, his slog is of high-quality and I might just use his slog when reviewing for the final exam!

(disclaimer: I wrote during the 9th week but forgot to upload from my word document so I am uploading now during week 10)

Week 8: My Impressions of Week 7

Coming back from reading week, I definitely was not as focused and engaged as I should have been. A lot of things were on my mind, including the upcoming 2^nd assignment and the potential strike of the TAs, which ended up happening and is still going strong as of now. At first glance, the assignment seemed just as challenging as the first one, if not more. However, since we were given starter code for the game_state and substract_square_state, it was therefore not nearly as abstract in that we were told exactly the functions to implement. This game was a lot tougher than the subtract square game but it was manageable. Once I designed a working board-like structure crucial to the game play, implementing the rest of the functions that were concerned with applying move, returning the possible next moves, and announcing the winner was not a problem. It was fairly straight-forward to earn the 40% that was attached to the tippy game state, tippy game move, and the annotations to the game view in order to play tippy.

 I wish I could say the same for the minimax strategy we had to implement but it was a tall order. It tested us thoroughly on our ability to apply our knowledge of recursion in a game theory context. Minimax is a strategy designed to guarantee victory so long as the player using this theory goes first and there is infinite time and information to make decisions. The player envisions all possible moves from a game state and what outcome each move will lead to, through many more possible next moves. The base case for this recursion case is to check the outcome of the game state (i.e. a win, loss, or tie). If the base case is not reached, this means that there are legal moves available. The process now is to consider each available move and the game states that each move could lead to. From here, the player using minimax is to basically pick a move that would not lead to his or her loss. Our group needed to take our sweet time to discuss a game plan to write the code for it. I was not as involved in the process as my other teammates were because I was more focused on writing the code for the tippy game state. However, I had great teammates who were able to manifest our plan into a working code, so I am grateful for that.

Even in class, I could tell my classmates and even the instructor were pre-occupied with thinking about the assignment. I was glad the instructor spent a good amount of time explaining possibly confusing things about the assignments because otherwise we would have been somewhat lost. The classroom content involved binary trees, which I found to be a particular extension of the tree concepts so I did not find the material to be too much of a jump from the week before. What I need to do is catch up a bit on reviewing class notes because I have been neglecting them in favour of excelling on the assignment. The second test is coming up, which means I need to get studying. Fun.

Week 7: My Summary of Recursion

As I mentioned in my recursion-tracing slog, the act of tracing recursive methods was quite simple. However, like anything else in CSC165 during the first semester and in this class, the first step to writing my own recursive function was quite difficult and I had no idea what the instructor was talking about. I sat down to really crack down on this problem. I first really read through the slides and examples that we went over in class and in the lab and tried to look for patterns. Functions are said to be recursive if they call themselves within their implementation to create repeating calls. Although the same process could be represented iteratively (i.e. with for and while loops), the instructor told us that for some problems, recursive functions are more concise and elegant, while loops can get long and complex pretty quickly.

The general pattern for more recursive functions is that they have two cases (sometimes three). The first case is known as the “base case”. This is for when even though the function might be recursive, the object might be simple enough to not require recursion. An if… expression is needed to check for that case. For a case that might be more complicated to deal with than the base case, an else… expression must be used. Ideally, this expression would reduce all the elements of the argument to the base case by iterating them through each element and calling on the same function (i.e. itself); hence, recursion. This is better explained using an example. Imagine if you want to find the number of all the elements in the list L = [1, 2, [3, 4], 5] with function element_amount(L). For a list, the base case would be a single integer element (e.g. 1) or just have the if statement check if it is not a list. It would return 1 because there is only one number. The more complex case would be invoked if the function was called on the list. Inside the else statement, we would have something like “sum([element_amount(x) for x in L])”. We’re breaking L into each element and putting them each into the element_amount function. This is with the hopes of inducing a base case for all of the elements, the sum of which will yield the number of elements in L.

To sum up, recursion is a way of finding solutions to a problem by breaking it down into smaller parts first and build up to a final solution with solutions of the smaller parts. What distinguishes this problem-solving method from the iterative way of problem-solving is that recursive functions are allowed to call themselves within their implementation. To succeed in implementing recursion, one must remember to break down the function into two cases: the first case being the base case that deals with a problem simple enough to yield a solution without requiring further recursion and the general case being the more complex case where the recursion call needs to take place. Recursion is a great way to solve problems because it makes the problem cleaner and breaks them down into more manageable means, which always leads to less headaches and working solutions!

Week 6: My Summary of Object-Oriented Programming Concepts

           The majority of the semester, except for this week and last week when we first dipped our toes with recursion, consisted of learning exactly what object-oriented programming is. If I were a betting man I would say that the expectation of this course is that we are able to fully understand and be able to explain what object-oriented programming, or “OOP” for short, is. Here is my best shot at it.

           The name of it is pretty self-explanatory. OOP is a type of programming process that revolves around devising procedures using objects as the information to solve real-life problems. Whenever the instructor threw around big words such as “Abstract Data Types” or “methods”, I reminded myself of the actual “Object-Oriented” part of the OOP name. What are objects? They are basically chunks of data you can store, manipulate, and extract. They can be Python built-in data types, such as integers, strings, and Boolean values, or you could even make your own. These are called Abstract Data Types, or “ADTs” for short. These store the intended meaning of the data it stores and what to do with them. Each ADT is organized as a “class”, which contains and neatly organizes “methods”. These are functions that can either report some property of the object the class represents, or mutate it. This all seemed super complicated to me at first because just the terms and concepts seemed super abstract. I fixed this by diving into analyzing examples, which the instructor was more than generous about. One of the examples was a Point object. A “Point” has coordinates, which has to be initialized first (I will explain later how that works). We also want its distance from the origin. A class would provide these services, both initializing the coordinates and returning its distance from the origin, through the methods that it houses. Not so hard to understand anymore, eh? Of course, we can get into much more detail with __eq__ and ___repr__ special methods and how to call upon the methods to use their services but the fundamental idea is that the classes and methods all revolve around how to perform operations with and/or on the main object that they were created to do, hence OOP.

           Inheritance, though, is a concept worth mentioning and the explanation of OOP would not be complete without it. Sometimes, we have an object that is kind of like one thing but is more specific. For example, a square and a triangle are shapes but they are more specific in that they are specific shapes. They share general attributes but determining them might require operations specific to their needs. The solution here is to create a parent class Shape and still implement methods. Then we can call Square and Triangle “subclasses”, which means that they inherit the methods but when we program the subclasses, we can override the inherited methods and add new methods that are only for that subclass. The endgame is that programmers are able to fully customize each class while doing minimal work if possible. Sounds like a perfect deal to me.

           Hopefully my explanation of OOP was clear enough for my classmates to understand. I know this stuff will come up on the final exam so I definitely look forward to coming back to this entry to review OOP concepts. I feel I can do quite a few things with this knowledge. As a matter of fact, my group (with Lukas and Jovan) did quite well in the first assignment, which dealt with practicing OOP so I think I’m set. I now look forward to more recursion to add to my toolbox along with OOP.

Week 5: My Impressions of Tracing Recursion from Week 4

           Boy, was I worried about recursion! My second-year friends and guys who I know took this course last semester built up quite the hype for me. The way I understand recursive functions is that it is a repeated application of a function within that same particular function. What I initially thought was why not just use for and while loops in the function when executing repeating operations. Well, I do know from learning about running time and efficiency in CSC165 that loops have n^2 running time, hence are not the most efficient way to go. My conjecture is that recursive functions are used because they are more efficient since I believe they are only n running time.

           Week 4 mainly just consisted of becoming introduced to the idea of recursion and being familiar with tracing them. It was not unlike the back in 108 when we were asked to determine the output of a function except obviously the difficulty did escalate with examples in this course. The functions primarily dealt with determining sums of the elements in the lists and the depth of some nested lists. The level of difficulty for me depended on what the functions were asking me to do. The functions determining sums of the elements were straight forward but for some reason and I can’t quite put a finger on it, but determining the depth of nested lists felt awkward. However, all in all, I felt that as long I read the code carefully both at first and every time I used the function, I could produce results that were accurate to the specifications of the functions. The instructor took it slow with the first tracing example, holding our hands through each operation in the function. That instilled in me the need to take things slow and be vigilant with each step. However, I realized last week in the lab that taking extremes with that will result in unnecessary tedium. The challenge for me now is to find that balance between being too tedious and being careless and rash when tracing recursion.

           If anything is the calm before the storm, this is it. Although tracing was not difficult, I am sure building recursive functions will be. I tried it by myself with the lab exercise and I struggled with it. Hopefully in the coming weeks the instructor shows us the methods and even some tricks to master creating recursive functions. I can’t wait!

Week 4: My Impression of the First Few Weeks

           Last semester, CSC108 closed with learning about what classes are and how and when to use them. This course started right where the previous course left off, except now it is more about using classes to represent abstract data types, or (ADTs). Python is known to provide many data types for objects by default (such as integers, strings, Boolean values, etc.) but there are not always data types that satisfy our needs when creating programs. For example, if we wanted an object to represent a student, we would want to store his name, student number, list of courses he is taking, etc. We would have to customize this using the pre-existing default data types and orient them in a way that is easy to extract and manipulate and use later. This is the way I understand object-oriented programming to be. The instructor made the content concise and clear so I definitely appreciate that. Since Python’s syntax is not overly complicated, this takes out one more variable for me to divert more effort into understanding the content better. You can always do better. My one gripe is that the examples shown in lecture were maybe too simple compared to the things we are asked to do for the first assignment. My group (with Jovan and Lukas) kind of struggled at first with understanding exactly what the assignment asked for and how to organize our classes to meet the specifications. However, as we learned more and more about class declarations and inheritance of classes, we knew to make subclasses and declaring exceptions on certain methods in superclasses to make ourselves a nice project. At least that is the hope. In terms of lectures, as long as I keep doing what I am doing (paying attention in lectures, reviewing notes after lecture, doing the assigned readings, etc.), I don’t foresee any problems happening in terms of understanding lectures. Although this course definitely takes things up a notch in difficulty compared to CSC148, I enjoy this material because lecture and lab examples include solving real-world problems and we are now learning how to be good designers and programmers, which is what I came here for.

           I read some of the slog entries from other students concerning last week’s topic, which was asking why geeks should write. I was especially intrigued by Ellery’s slog entry (http://zhexinlai.blogspot.ca/). She thinks geeks should write because they communicate a lot with non-human objects and therefore have expertise in handling them. Since non-human objects cannot verbally communicate and regular people sometimes have trouble dealing with them, geeks would be doing everyone a service by bridging their gap by writing. I think Ellery’s idea is awesome. I only thought about this topic from the geek’s point of view, not how they could help society like she did. Other slogs had equally intriguing ideas, some in line with mine, some totally different. 

Week 3: Why Geeks Should Write

According to dictionary.com, a “geek” is best described as a person who displays excessive enthusiasm for and a high level of expertise on a particular subject or activity while being somewhat reclusive and socially awkward. I have noticed from various courses last semester that a considerable number of people display some or all of the defined characteristics of a “geek”, for a lack of a better term (since the term “geek” could have a derogatory connotation). They were highly motivated not only for academic success but for self-exploration and augmentation beyond the minimum requirements, while not necessarily making social interaction their top priority. This is a waste of potential, as good ideas are meant to be shared yet the absence of social interaction makes sharing non-existent.

I understand that sometimes people can be shy or people just do not like talking to others. A great alternative to talking is, of course, writing. It does not require the effort of socialization so that variable is completely taken out. Writings are judged only on the quality of writing and the content. Geeks, who have dedicated themselves to their craft, should be confident about producing good content and anybody can be a solid writer with practice and due diligence. Writings can be distributed far and wide, especially in today’s world with the Internet, so a person from Africa can read and learn from ideas that another person for Australia produced to change or build upon his or her own ideas. Your ideas will also be exposed more, which is a good thing, since more people can benefit from them and provide you with feedback. Writing is a means of interaction with the outside world without the exertion of effort to socialize that geeks could feel.

It would also be prudent for geeks to write for the sake of recording their work.  They sometimes produce ideas at such a pace that old ideas might be forgotten and if not recorded, lost forever. I learned last semester from the slogs in CSC165 that reflection is very important. Towards the end of the semester, I was scrambling to find out what weaknesses I had in CSC165 to shore them up for the final exam. The slog had everything in it because I had been diligent in recording my struggles. Geeks should write down their current exploits so that in the future, they can use the accumulated knowledge to solve problems that they might have struggled in the past. The past could also serve as inspiration for current or future projects.

This is my opinion on why geeks should write, primarily for sharing and recording their ideas. I would love for my fellow CSC148 students to comment on this slog entry to give feedback on my opinion. I will also be reading and commenting other slogs to check out their opinions on the matter.