Feb 13: Filter, Zip, and A1
This week in lab I learned about the zip function. This function takes at least 2 lists, and creates a new one with tuple entries corresponding to the first items in both. So, for example, if I had a = [1, 2, 3] and b = [a, b, c], zip(a,b) would give me [(1,a), (2,b), (3,c)]. This is like a matrix concatenation of sorts and was also exemplified in the lab, where it was used for some basic linear algebra functions.
The lab was great. We got to strip down and rewrite dot and cross product functions without using list comprehensions; we built them up form scratch. For example, the filter list comprehension is both a loop and an if statement in one line, and is a much more efficient way of 'filtering' whether to do something or not, but once we rewrote it as the original loop structure, I could better understand what was actually happening inside.
We finished assignment 1. Actually using the things we have learned over the last 6 weeks in such a dynamic setting greatly enhanced my understanding of OOP. Inheritance, subclass, method headers, the init, I now understand all of these. I was impressed with how streamlined and efficient the OOP code allows this game to be. As we programmed it, we 'built' up from the ground and got to see the various functions pass objects back and forth between each other. So it made sense that console controller wouldn't work without TOAHModel, and etc.
I also finally understand the if name == main; all somebody had to tell me was that whatever code you write underneath will be executed when the program runs. I also zeroed in on instantiation as I had a huge problem where my console controller was trying to run a general model (i.e TOAHModel()), but now I understand that to create an instance of the game I had to take one particular case that inherits from the class, so for example game1 = consolecontroller(4) which was then passed onto TOAHModel and instantiated as one instance of the TOAHModel class. The TA really helped with this.
Lastly, on a1 recursion. Originally I thought I had to establish a base case for the Tour min moves function M(n), but a friend suggested a better approach (I thought).
Instead of working backwards to the base case, we built 2 loops that accumulated the i value giving us the min moves value, and a list of the corresponding Ms. So this was really like a reverse recursion where we built the list going forward, meaning that to solve n = 6 you need to know all the previous ones, but they had been built up for you. This really interested me as I think in this instance a simple loop structure accomplished the same task but in a way that seemed way more intuitive to me. In terms of OOP, I mean I was surprised to see that there may be more than one approach and that everything I've learned in class is really a tool, to be used depending on what the situation calls for.
Finally, I've found a much quicker way to deal with raising assertions, using 1 or 2 lines and an assert condition with a comma and the message following after.
This week in lab I learned about the zip function. This function takes at least 2 lists, and creates a new one with tuple entries corresponding to the first items in both. So, for example, if I had a = [1, 2, 3] and b = [a, b, c], zip(a,b) would give me [(1,a), (2,b), (3,c)]. This is like a matrix concatenation of sorts and was also exemplified in the lab, where it was used for some basic linear algebra functions.
The lab was great. We got to strip down and rewrite dot and cross product functions without using list comprehensions; we built them up form scratch. For example, the filter list comprehension is both a loop and an if statement in one line, and is a much more efficient way of 'filtering' whether to do something or not, but once we rewrote it as the original loop structure, I could better understand what was actually happening inside.
We finished assignment 1. Actually using the things we have learned over the last 6 weeks in such a dynamic setting greatly enhanced my understanding of OOP. Inheritance, subclass, method headers, the init, I now understand all of these. I was impressed with how streamlined and efficient the OOP code allows this game to be. As we programmed it, we 'built' up from the ground and got to see the various functions pass objects back and forth between each other. So it made sense that console controller wouldn't work without TOAHModel, and etc.
I also finally understand the if name == main; all somebody had to tell me was that whatever code you write underneath will be executed when the program runs. I also zeroed in on instantiation as I had a huge problem where my console controller was trying to run a general model (i.e TOAHModel()), but now I understand that to create an instance of the game I had to take one particular case that inherits from the class, so for example game1 = consolecontroller(4) which was then passed onto TOAHModel and instantiated as one instance of the TOAHModel class. The TA really helped with this.
Lastly, on a1 recursion. Originally I thought I had to establish a base case for the Tour min moves function M(n), but a friend suggested a better approach (I thought).
Instead of working backwards to the base case, we built 2 loops that accumulated the i value giving us the min moves value, and a list of the corresponding Ms. So this was really like a reverse recursion where we built the list going forward, meaning that to solve n = 6 you need to know all the previous ones, but they had been built up for you. This really interested me as I think in this instance a simple loop structure accomplished the same task but in a way that seemed way more intuitive to me. In terms of OOP, I mean I was surprised to see that there may be more than one approach and that everything I've learned in class is really a tool, to be used depending on what the situation calls for.
Finally, I've found a much quicker way to deal with raising assertions, using 1 or 2 lines and an assert condition with a comma and the message following after.
No comments:
Post a Comment