Wednesday, February 26, 2014
Week 7 - Linked Lists
So after a much needed "break" from school, this week we learned about Linked Lists. These are essentially Trees with a branching factor of 1. The reason for this datatype is so that we may decrease the amount of time an operation takes in a function given its parameter. In our labs, we're just getting familiar with linked lists so that in the future, we can see how linked lists can be used a lot more efficiently compared to nested lists. Dan showed that the linear growth of a list takes a long time to operate on, and that linked lists are used to speed that up.
Friday, February 14, 2014
Week 6 - Trees
This week, we learned about a new type of data structure called Trees. This method of organizing data is used when the data you have is not in a linear structure (For example: Stacks, Lists, Queues, ect.).
With Trees, its not always obvious to organize things in a linear manner, instead, the idea of hierarchy is used to organize the data.
The basis of a tree structure consists of Nodes and Edges. Nodes can be thought of as a "point" in a tree (like the seed, or leaves), while Edges "connect" these Nodes together (much like branches). The main methods used for a Tree structure are traversing through, inserting/removing nodes, and inserting/removing subtrees at a Node.
Overall, the terminology and the overall concept of tree's aren't that hard to understand. Hopefully understanding the code will be just as easy.
With Trees, its not always obvious to organize things in a linear manner, instead, the idea of hierarchy is used to organize the data.
The basis of a tree structure consists of Nodes and Edges. Nodes can be thought of as a "point" in a tree (like the seed, or leaves), while Edges "connect" these Nodes together (much like branches). The main methods used for a Tree structure are traversing through, inserting/removing nodes, and inserting/removing subtrees at a Node.
Overall, the terminology and the overall concept of tree's aren't that hard to understand. Hopefully understanding the code will be just as easy.
Sunday, February 9, 2014
Week 5 - Recursions (again)
This week was very similar to the last, we pretty much only went through a few examples on recursive functions. All my thoughts can be found in the Week 4 post.
Saturday, February 1, 2014
Week 3 - Exceptions
Unfortunately I underwent a surgery this week and was unable to attend the entire week. However, that didn't stop me from reading through the slides and pages on exceptions...
The concept of "catching" errors and dealing with them is something I thought of last semester in CSC108 where I would think of all the possible cases for a function. I would create a function that would require a certain argument, but I would design the function so that the argument must have a special case to it (ie. a list with n length that must have the int 3..a special case like that.), I would then make the function return a string stating that the argument isn't "correct" (ie. "This list doesn't have the int 3"). I would think of things like this and thought why there isn't a built in way of doing this with python.
Luckily there was a built in way to catch these "mistakes" through the use of user defined exceptions. The concept is very similar to what I had in mind originally except its a more "official" way of doing it. E2 was assigned to test your abilities with using and understanding exceptions, and fortunately I was able to complete the exercise with little struggle...I'm sure everyone else in the course did too, but its just that I feel a lot more rewarded when I essentially learned the concept of exceptions on my own.
The concept of "catching" errors and dealing with them is something I thought of last semester in CSC108 where I would think of all the possible cases for a function. I would create a function that would require a certain argument, but I would design the function so that the argument must have a special case to it (ie. a list with n length that must have the int 3..a special case like that.), I would then make the function return a string stating that the argument isn't "correct" (ie. "This list doesn't have the int 3"). I would think of things like this and thought why there isn't a built in way of doing this with python.
Luckily there was a built in way to catch these "mistakes" through the use of user defined exceptions. The concept is very similar to what I had in mind originally except its a more "official" way of doing it. E2 was assigned to test your abilities with using and understanding exceptions, and fortunately I was able to complete the exercise with little struggle...I'm sure everyone else in the course did too, but its just that I feel a lot more rewarded when I essentially learned the concept of exceptions on my own.
Subscribe to:
Comments (Atom)