Well, we're gonna have to revisit one of our old SLOG posts and reflect on them, so we might as well dive into them.
One of the most common concepts that we've often encountered throughout CSC148 was recursion - that is, when a function calls itself for the purpose of reducing input to the smallest base case, and working from there. Initially, I felt that recursion was something that was too overemphasized, and was less significant than the traditional iterative methods of programming. The factorial question can emphasize this; we could simply iterate through from 1 to n, multiplying each value to the total to achieve our factorial value. This was effective, correct and fast. Its recursive version was albeit a bit confusing, and its functionality was limited. So why did we even bother about recursion?
It turns out that recursion was a useful tool in the wide world of data structures - by being able to perform actions that iteration is limited in. For a challenge, we can do this by trying to implement an iterative method for binary search trees; it would be frustrating to implement. Recursion offers us a form of problem solving that is efficient in reducing the overall weight of a problem. For example, when using recursion on binary search trees, it makes sense because, for example, when we try to search for a value we would traverse through each subtree in the hopes of achieving the simplest case possible - either when the value is not found, or when the value is reached. Ultimately, the point of recursion is simple; to break down problems to simpler versions of itself, and nonetheless.
Furthermore, I would also like to add that recursive functions are, in a sense, 'cleaner' and a tad bit more 'readable' than an iterative function. Proof of this can be visualized in the form of 'for loops'. In for loops, we would iterate through n values and do stuff with them. When we have multiple statements that we would like to do inside of them, they can get messy and be difficult to read. I know because I have had some troublesome experiences reading other peoples' 'for' loops, especially when there were many statements and executions in them. Recursion, on the other hand, is simpler; just a base case, and a recursive case and that's all to it. Granted, recursion can be a bother to trace in some occasions, but compared to iterative functions, are at least a little bit more nicer to come by if implemented correctly.
In conclusion, recursion > iterative loops because they are cleaner, support a wide variety of applications that iterative functions are limited to, and are much easier to delve through than large, iterative blocks.
Wednesday, 25 March 2015
Tuesday, 17 March 2015
A Hectic Week (Week 9)
Whew! Week 8 was one heck of a week! Between two assignments (one for CSC165 and for CSC148) and two term tests for the same two courses above, I can't believe that I managed to survive this week.
To begin with, after weeks of procrastination (ouch!) and a rather frustrating date with the minimax program, me and my partner took it upon ourselves to visit Danny Heap's office hours to figure out this minimax problem. We got one thing out for sure; our code wasn't working as the assignment told us to do, and Danny really showed us an interesting way to think about minimax. Unfortunately, after all that, my minimax solution did not work out as expected (it worked for subtract square but was a complete dork at tippy), but it was an eye-opener for me to the world of AI design. This was a rather interesting assignment as it was my first real encounter with a "smart" AI function for a game, and on implementing such. I felt that this AI implementation should be more suited for a later, upper-year course (in my opinion), but on the other hand, it was an interesting way to look at artificial intelligence implementations. After all, as my peers, parents and the world out there have pointed out, AI is going to be a big thing in the future years ahead, so you could say that this will be a painful, but rewarding experience for me in later years as a CS student at UofT.
Next came the test. This test was quite a worrying factor for me. I didn't do well on the first test - to be honest, it was easy but I choked Toronto Maple Leafs-style on one of the questions and lost major marks - so this time I was determined to kill/murder/do good on this test. I basically went over the labs we did in class, for study purposes, and taught myself how to implement linked lists in code - which, for me, was difficult due to the ongoing strike conditions.
One of the things that was difficult for me to comprehend about linked lists was how to represent them. In class, we were shown pictorial representations of linked lists, which described what linked lists were meant to imitate. However, when I went to compute some problems on my own, I found the diagrams difficult to understand. It wasn't until I went to Danny Heap's office hours that, on my own (and with a friend to help) that for me, it was easier to represent linked lists in their code form. So rather than this:
25 -> 69 -> 10 -> X
I found that this was easier for me to work with, and trace through:
LLNode(1, LLNode(2, LLNode(3)))
Apparently the latter was more convenient and an organized way for me to think of linked lists.
Luckily, the test day came and I found the test to be easier than expected. From the past tests they were difficult to comprehend and trying to work the answers on my own were a disaster. I did get some resolve from Danny Heap assuring that the test would be based on lab questions - which they were - and it was a great relief. Ultimately, thank you Danny Heap for your help and your determination to help us succeed!
Here's to a good mark on my test!
+ Slava Gospodu! Praise the Lord! +
To begin with, after weeks of procrastination (ouch!) and a rather frustrating date with the minimax program, me and my partner took it upon ourselves to visit Danny Heap's office hours to figure out this minimax problem. We got one thing out for sure; our code wasn't working as the assignment told us to do, and Danny really showed us an interesting way to think about minimax. Unfortunately, after all that, my minimax solution did not work out as expected (it worked for subtract square but was a complete dork at tippy), but it was an eye-opener for me to the world of AI design. This was a rather interesting assignment as it was my first real encounter with a "smart" AI function for a game, and on implementing such. I felt that this AI implementation should be more suited for a later, upper-year course (in my opinion), but on the other hand, it was an interesting way to look at artificial intelligence implementations. After all, as my peers, parents and the world out there have pointed out, AI is going to be a big thing in the future years ahead, so you could say that this will be a painful, but rewarding experience for me in later years as a CS student at UofT.
Next came the test. This test was quite a worrying factor for me. I didn't do well on the first test - to be honest, it was easy but I choked Toronto Maple Leafs-style on one of the questions and lost major marks - so this time I was determined to kill/murder/do good on this test. I basically went over the labs we did in class, for study purposes, and taught myself how to implement linked lists in code - which, for me, was difficult due to the ongoing strike conditions.
One of the things that was difficult for me to comprehend about linked lists was how to represent them. In class, we were shown pictorial representations of linked lists, which described what linked lists were meant to imitate. However, when I went to compute some problems on my own, I found the diagrams difficult to understand. It wasn't until I went to Danny Heap's office hours that, on my own (and with a friend to help) that for me, it was easier to represent linked lists in their code form. So rather than this:
25 -> 69 -> 10 -> X
I found that this was easier for me to work with, and trace through:
LLNode(1, LLNode(2, LLNode(3)))
Apparently the latter was more convenient and an organized way for me to think of linked lists.
Luckily, the test day came and I found the test to be easier than expected. From the past tests they were difficult to comprehend and trying to work the answers on my own were a disaster. I did get some resolve from Danny Heap assuring that the test would be based on lab questions - which they were - and it was a great relief. Ultimately, thank you Danny Heap for your help and your determination to help us succeed!
Here's to a good mark on my test!
+ Slava Gospodu! Praise the Lord! +
Saturday, 7 March 2015
Data Structures (Week 8)
During week 8 we spent a lot of time trying to finish assignment 2 - where we had to implement another game state for Tippy - a tic tac toe variation where the object of the game was to create a sequence of X's or O's that formed the Z or S tetromino found in Tetris. While the game state itself was not difficult to implement, the minimax strategy - which was designed such that the AI would always pick the best possible move - was a pain to build. I will admit though, even though the explanation of how to approach the design was somewhat simple, how to codify it using Python was difficult as it can be. I spent many hours working on this, including time at Danny's office hours - in the end, my minimax would be strong for subtract square but a complete dork at Tippy. Hopefully my effort though, won't go to waste.
In previous weeks, we were introduced to several data structures - trees, binary trees and binary search trees; those ones were basically variations of each other. A tree would basically be a data structure in which data was represented as a node - or an individual object - which would point to other objects of the like - known as its children. Nodes without children were called leaves, and nodes with children would be root nodes of such children. Ultimately, the design of the tree was such that it would implement recursion to travel down the trees, and whatnot. Binary trees, on the other hand, followed the same idea as the generic tree structure, but instead of being able to have nodes that branched to n other nodes, binary trees could only have two. Furthermore, binary search trees, on the other hand, derived from binary trees, but differ in the fact that binary search trees could only have two nodes - the left node's value being smaller than its root node's and the right node's value being larger than its root node's!
Then we moved on to linked lists. One could consider linked lists to be a variation of lists, but like the tree, each value would be represented as its own object. A node in a linked list would contain two pieces of information - what value it held, and what other node(s) it pointed to. Intuitively, this was not difficult to visualize in the mind. For me, being bogged down on assignment 2 caused me to be a step back in understanding linked lists, and as such I spent an entire Thursday focusing on the implementation of linked lists - and their functions.
We are going to have a midterm on data structures soon, and I am almost at my breaking point. Between a CSC148 test on Wednesday I also have a CSC165 test on Tuesday (which mainly consists of practicing proofs and whatnot), and a religion essay due on March 12, which I haven't started to revise. Yes, this week is going to be a bummer.
Subscribe to:
Comments (Atom)