Hello fellow survivors!
I'd like to transport you back to Week 4, and to my post cleverly entitled "So Far, So Good". At this point, I was feeling pretty good about how the semester was going. Of course this was before the disaster that was the TA strike and Assignment 2 (yes, I associate both of those events to be equivalently as horrible and tramatisizing).
I'd like to quote myself: "I hope this post doesn't jinx all that." Well, past Anisha, I hope you're happy because you did jinx it, you've jinx'd everything. It was after this post that we began the rollercoaster of emotions that was recursion (first interested, then depressed, then incrediblly proud, then assignment 2 and thus hate, then assignment 3 and thus happiness). It was after this post that Assignment 2 became a thing (is it becoming clear to anyone else how much I hate assignment 2?).
But it wasn't all bad. Assignment 3 actually takes me back to the same passive, netural-ness that caused the week 4 post. What I mean by that is I enjoyed Assignment 3 so much that it balanced out my hatred of Assignment 2, which is amazing.
On the other hand, my feelings or relief, exhurbance, and pride, that I described in Week 4 has only gotton worse. Or better. Either way, my point is that when I get something in this course, I just have this incredible high, which is actually a bit pathetic considering there are probably many people who do not find this material as challenging as I do. But that's okay because at least I usually do get it (except Assignment 2, but let's not talk about that).
Studying for written tests is still not fun, but I'm a bit more sympathtic as to its necessity to this course. Now I feel that perhaps one of the two midterms should be written and the other done on computers. And while, I regognize the difficulty of doing an online test, I feel that it is still worth it because it is a clearer indication of our abilities.
Overall, not much has changed, though I feel as though I personally have grown. (Ugh, the cliche of that, I apologize.)
Feeling slightly embrassed about the coloquialness of my previous posts (and this post),
- Anisha Rohra
Friday, March 27, 2015
Sunday, March 1, 2015
I DID IT! (Week 8)
Last week brought great excitement for me because I was able to successfully code the lab's recursive code without too much trouble. Granted, it wasn't particularly difficult, but it was still a shining moment for me because of the difficulty that I've had with recursion. Both my understanding of how it works and my inability to come up with that additional required function to code it (minimax).
On the plus side, I think I'm getting better. And gradually realizing just how convinent it is to compared to non-recursive code. I was thinking as I wrote the code for the lab, that while some of the code could have been easier to write without recursion, it would have been longer and more unecessary. As Danny puts it, the code is deeper but significantly shorter, and intuitively it feels more effecient. I suppose I'll learn whether it is actually more effecient when we cover that unit in class.
What else did we do last week? Me and my partner started Assignment 2. I don't know how I feel about the fact that we're going to be spending hours (hours!) coding such a simple game; yes part of it is because we're using classes and recursion, and really the point is not the game. I just wish we had a little more that indicates the sheer amount of time this stuff requires. Hopefully future compsci courses will have something more satisfying (no offence to anyone who may be reading this!).
Otherwise though, this is proving to very difficult. Minimax is hard to wrap the mind around, let alone code, and reading the code for SubtractSquareState provided to us and comparing it to what we did on Assignment 1 is really a blow to the ego. But this is a learning process. Though I will say, I appreciate that there isn't one fixed way to do something and I feel validated in disagreeing with some of the more stylistic choices made by the professors. What I'm getting at is that I feel computer science and these assignments in particular involve quite a bit of individuality, and as a humanities-minded person, I greatly enjoy that.
That's all for now, folks!
- Anisha Rohra
On the plus side, I think I'm getting better. And gradually realizing just how convinent it is to compared to non-recursive code. I was thinking as I wrote the code for the lab, that while some of the code could have been easier to write without recursion, it would have been longer and more unecessary. As Danny puts it, the code is deeper but significantly shorter, and intuitively it feels more effecient. I suppose I'll learn whether it is actually more effecient when we cover that unit in class.
What else did we do last week? Me and my partner started Assignment 2. I don't know how I feel about the fact that we're going to be spending hours (hours!) coding such a simple game; yes part of it is because we're using classes and recursion, and really the point is not the game. I just wish we had a little more that indicates the sheer amount of time this stuff requires. Hopefully future compsci courses will have something more satisfying (no offence to anyone who may be reading this!).
Otherwise though, this is proving to very difficult. Minimax is hard to wrap the mind around, let alone code, and reading the code for SubtractSquareState provided to us and comparing it to what we did on Assignment 1 is really a blow to the ego. But this is a learning process. Though I will say, I appreciate that there isn't one fixed way to do something and I feel validated in disagreeing with some of the more stylistic choices made by the professors. What I'm getting at is that I feel computer science and these assignments in particular involve quite a bit of individuality, and as a humanities-minded person, I greatly enjoy that.
That's all for now, folks!
- Anisha Rohra
Monday, February 23, 2015
An Attempt to Describe the Indescribable (Week 7)
Hello fellow recursion-beginners!
This post is my attempt to summarize recursion. Bear in mind that my grasp on the concept is weak, having had only a few weeks to wrap my head around what is undoubtedly a complex and mind-bending concept. It requires, I think, a little bit of trust in the computer that it will be able to follow the logic behind the code even though you don't really know the specifics of how it does so.
Before I begin, I would like to state that my definitions and explanations may not be entirely correct, as their main purpose is to describe the phenomenon of recursion, not necessarily to provide accurate definitions and explanations. In other words, I intend to be more colloquial than I probably ought to be.
So as I see it, recursion is the phenomenon of calling a function within its own code in order to avoid repetitive code and allow for deeper functions that do not rely on repeated for loops or unnecessarily long code. An example of a useful instance of recursive code is when dealing with class Tree- a sueful structure for several reasons, and unfortuneately requiring quite a bit of recusion.
Recursive functions require a base case. That is to say, the simplest situation in which no recursion is necessary. Often, this base case will be implemented frequently, at the end of every recursive call, so be careful when choosing both its condition and its code. Recursion base case looks like the following:
def count_nodes(tree):
if tree.children == []:
return 1
The code under the else clause will be the recusrive code. What we've learned so far is that there should be another function that is used to keep track of the information gathered in all the recursion calls. So in this example, if we are attempting to count the number of nodes in a tree, the else clause would look like the following:
else:
return 1 + sum([count_nodes(x) for x in tree.children])
What will happen here is that if the node that we've entered had no children, the function would return 1 for 1 node, the parent node. Otherwise, it returns 1 and then goes through each child node to check if it to has a child, until finally it hits a leaf node without children at which point it will move on to the next child node. This process goes on until every node has been hit and somewhat magically, all those 'return 1' gets added together and returned.
There is an element of trust required with recursion functions. I'm not quite sure how all those 1's were stored without a variable but I do know that it works. So I trust in it and I move on. Perhaps not the smartest thing, but it's working for me for the time being.
So this has been my summary or recursion. Hopefully I can come back to this post after a few weeks and have a lot more to say about recursion.
This has been an attempt to describe the indescribable.
Thanks and talk to you next week!
- Anisha Rohra
Before I begin, I would like to state that my definitions and explanations may not be entirely correct, as their main purpose is to describe the phenomenon of recursion, not necessarily to provide accurate definitions and explanations. In other words, I intend to be more colloquial than I probably ought to be.
So as I see it, recursion is the phenomenon of calling a function within its own code in order to avoid repetitive code and allow for deeper functions that do not rely on repeated for loops or unnecessarily long code. An example of a useful instance of recursive code is when dealing with class Tree- a sueful structure for several reasons, and unfortuneately requiring quite a bit of recusion.
Recursive functions require a base case. That is to say, the simplest situation in which no recursion is necessary. Often, this base case will be implemented frequently, at the end of every recursive call, so be careful when choosing both its condition and its code. Recursion base case looks like the following:
def count_nodes(tree):
if tree.children == []:
return 1
The code under the else clause will be the recusrive code. What we've learned so far is that there should be another function that is used to keep track of the information gathered in all the recursion calls. So in this example, if we are attempting to count the number of nodes in a tree, the else clause would look like the following:
else:
return 1 + sum([count_nodes(x) for x in tree.children])
What will happen here is that if the node that we've entered had no children, the function would return 1 for 1 node, the parent node. Otherwise, it returns 1 and then goes through each child node to check if it to has a child, until finally it hits a leaf node without children at which point it will move on to the next child node. This process goes on until every node has been hit and somewhat magically, all those 'return 1' gets added together and returned.
There is an element of trust required with recursion functions. I'm not quite sure how all those 1's were stored without a variable but I do know that it works. So I trust in it and I move on. Perhaps not the smartest thing, but it's working for me for the time being.
So this has been my summary or recursion. Hopefully I can come back to this post after a few weeks and have a lot more to say about recursion.
This has been an attempt to describe the indescribable.
Thanks and talk to you next week!
- Anisha Rohra
Saturday, February 7, 2015
Recursion, Retracing, and Regret (Week 5)
Hello fellow recursion-ists!
I'm going to be upfront about something here- I didn't go to class last week.
*Gasp!*
What I'm most struck by with recursion is that there is something intuitively that feels wrong with referencing a method in its own definition- it feels like it should create an infinite loop. It took quite a bit of extremely outlined tracing before I understood why it didn't create an infinite loop- the if/else clause that breaks the loop when such a thing becomes necessary.
What I'm still a little struck by is why the professor seems to prefer recursion to the longer, but more straightforward, way of coding these programs. I think it'll take a while before I accept that this is better way to do things. But I think I do agree that it opens a world of possibilities.
Also, I'm wondering about the confining base case method of approaching recursion. Can we use recursion without a base case? How about in a for loop? How would that work? Wouldn't the 'return' statement in the base case cause the loop to remain unfinished?
In short, I am left with many questions about recursion and remain apprehensive about its worth- especially considering how confusing I find it.
((Also I will not be skipping any classes any time soon!))
So long, and thanks for all the fish!
- Anisha Rohra
I'm going to be upfront about something here- I didn't go to class last week.
*Gasp!*
I know, I know. This was a bad bad idea, because of course, we learned something quite important last week and I unfortunately had to teach myself how to trace recursions. I'm afraid to say I wasn't very successful at it, because the concept still confuses me a bit.
What I'm most struck by with recursion is that there is something intuitively that feels wrong with referencing a method in its own definition- it feels like it should create an infinite loop. It took quite a bit of extremely outlined tracing before I understood why it didn't create an infinite loop- the if/else clause that breaks the loop when such a thing becomes necessary.
What I'm still a little struck by is why the professor seems to prefer recursion to the longer, but more straightforward, way of coding these programs. I think it'll take a while before I accept that this is better way to do things. But I think I do agree that it opens a world of possibilities.
Also, I'm wondering about the confining base case method of approaching recursion. Can we use recursion without a base case? How about in a for loop? How would that work? Wouldn't the 'return' statement in the base case cause the loop to remain unfinished?
In short, I am left with many questions about recursion and remain apprehensive about its worth- especially considering how confusing I find it.
((Also I will not be skipping any classes any time soon!))
So long, and thanks for all the fish!
- Anisha Rohra
Thursday, February 5, 2015
So Far, So Good (Week 4)
Hello fellow CSC148 monthers!
That's right, it's been an entire month in this course, and my emotions can only be summed up with "so far, so good". I hope that this post doesn't jinx all that.
Assignment 1 was much more difficult than anything we'd done in CSC108, but I'm slowly discovering that the best thing about more difficult assignments in the sheer sense of relief and exuberance that comes when you finally get it! It's unlike anything I've felt before, because that just doesn't happen when you finish an English essay or write a math test. And while getting a good mark can instill a sense of pride, it's never quite as reliving and uplifting as finally getting the code that you've been working on for perhaps hours.
On the other hand, studying for this test has not been fun. I will never understand why it is necessary to write code by hand. Yes, programmers shouldn't rely on testing methods for simple code, but it is my opinion that by asking us to write out code, you're limiting the kinds of questions you can ask us, and ultimately failing to get a full grasp on the kind of programmers we are. In fact, I cannot wait until the assignments are such that there are multiple ways to approach them and thus the code can be a lot more individualized (in short, I'm looking for more freedom).
Well, coming back from that tangent, so far, things have been going really well. I'm anxious though, because I know it's only going to get tougher from here.
Talk to you later!
- Anisha Rohra
That's right, it's been an entire month in this course, and my emotions can only be summed up with "so far, so good". I hope that this post doesn't jinx all that.
Assignment 1 was much more difficult than anything we'd done in CSC108, but I'm slowly discovering that the best thing about more difficult assignments in the sheer sense of relief and exuberance that comes when you finally get it! It's unlike anything I've felt before, because that just doesn't happen when you finish an English essay or write a math test. And while getting a good mark can instill a sense of pride, it's never quite as reliving and uplifting as finally getting the code that you've been working on for perhaps hours.
On the other hand, studying for this test has not been fun. I will never understand why it is necessary to write code by hand. Yes, programmers shouldn't rely on testing methods for simple code, but it is my opinion that by asking us to write out code, you're limiting the kinds of questions you can ask us, and ultimately failing to get a full grasp on the kind of programmers we are. In fact, I cannot wait until the assignments are such that there are multiple ways to approach them and thus the code can be a lot more individualized (in short, I'm looking for more freedom).
Well, coming back from that tangent, so far, things have been going really well. I'm anxious though, because I know it's only going to get tougher from here.
Talk to you later!
- Anisha Rohra
Saturday, January 24, 2015
Geeks and Writing: Let's Talk About the Hitchhiker's Guide to the Galaxy (Week 3)
Hello fellow Geeks!
I'm coming into this computer science course and program with a long-held and deep appreciation of the written word. I'm so appreciative of it that I'm hoping to major in both computer science and english during my undergraduate years. So this week's topic is both significant and perfect for me.
The Hitchhiker's Guide to the Galaxy, for those that don't know, is a sci-fi classic about a universe filled with living beings and habitable planets outside of Earth. Actually Earth seemingly has nothing to do with the novel at all, largely because it gets blown up within the first 20 pages. The book is hilarious but more importantly, it somehow manages to intertwine the sciences and the humanities brilliantly. It talks about how philosophers would go out of business if science were to discover the meaning of life while making a deliberate point about how the meaning of life will remain as elusive within the confines of science as it continues to within philosophy. The novel introduces us to depressed robots, sassy AI's, misunderstood dolphins, and a blurred line between science and the arts like I've never read or seen before. Basically, I love this book.
But why I am talking about this here? Because I think the novel, and really the entire sci-fi genre, exemplifies how important it is that geeks learn to write so that we can take our pent-up creativity and imagination and let it loose, because its only through the imagination of geeks that we've gotten as far as we have with technology, that we've reached such impossible standards with machines and computers. You need an idea before you can program and the only way to get those ideas is through the outlet that writing can provide. The Hitchhiker's Guide to the Galaxy presents improbabilities and impossibilities but it also presents inspiration for a future once unimaginable to us, now significantly more within our grasps. In other words, I refuse to believe that I will never have a pet Marvin and am now determined to make him myself if I have to.
There is, of course, a more practical reason to learn to communicate effectively and efficiently. As we're learning in class right now, there's a great deal of importance in being able to share our codes with other people. In order for people to use and appreciate our wonderful codes, they have to be able to understand our codes. The easiest way to do this is through the docstrings and design recipe that has been drilled into our brains. But if we can't write those docstrings with a certain level of clarity and specificness then no one will be able to understand us and our amazing codes will be useless to everyone but ourselves.
The blending of scientific imagination and artistic creativity is a deadly combination that can, as cheesy as this is, change the world. Our most famous artists are some of our most famous scientists, and that's no coincidence. Geeks need to learn to write, yes so they can communicate their ideas, but also to bring their ideas to life and imagine the unimaginable.
That's all from me this week!
So long, and thanks for all the fish.
- Anisha Rohra
I'm coming into this computer science course and program with a long-held and deep appreciation of the written word. I'm so appreciative of it that I'm hoping to major in both computer science and english during my undergraduate years. So this week's topic is both significant and perfect for me.
The Hitchhiker's Guide to the Galaxy, for those that don't know, is a sci-fi classic about a universe filled with living beings and habitable planets outside of Earth. Actually Earth seemingly has nothing to do with the novel at all, largely because it gets blown up within the first 20 pages. The book is hilarious but more importantly, it somehow manages to intertwine the sciences and the humanities brilliantly. It talks about how philosophers would go out of business if science were to discover the meaning of life while making a deliberate point about how the meaning of life will remain as elusive within the confines of science as it continues to within philosophy. The novel introduces us to depressed robots, sassy AI's, misunderstood dolphins, and a blurred line between science and the arts like I've never read or seen before. Basically, I love this book.
But why I am talking about this here? Because I think the novel, and really the entire sci-fi genre, exemplifies how important it is that geeks learn to write so that we can take our pent-up creativity and imagination and let it loose, because its only through the imagination of geeks that we've gotten as far as we have with technology, that we've reached such impossible standards with machines and computers. You need an idea before you can program and the only way to get those ideas is through the outlet that writing can provide. The Hitchhiker's Guide to the Galaxy presents improbabilities and impossibilities but it also presents inspiration for a future once unimaginable to us, now significantly more within our grasps. In other words, I refuse to believe that I will never have a pet Marvin and am now determined to make him myself if I have to.
There is, of course, a more practical reason to learn to communicate effectively and efficiently. As we're learning in class right now, there's a great deal of importance in being able to share our codes with other people. In order for people to use and appreciate our wonderful codes, they have to be able to understand our codes. The easiest way to do this is through the docstrings and design recipe that has been drilled into our brains. But if we can't write those docstrings with a certain level of clarity and specificness then no one will be able to understand us and our amazing codes will be useless to everyone but ourselves.
The blending of scientific imagination and artistic creativity is a deadly combination that can, as cheesy as this is, change the world. Our most famous artists are some of our most famous scientists, and that's no coincidence. Geeks need to learn to write, yes so they can communicate their ideas, but also to bring their ideas to life and imagine the unimaginable.
That's all from me this week!
So long, and thanks for all the fish.
- Anisha Rohra
Subscribe to:
Comments (Atom)