This week the second part of A2 was due, which involved 4 functions; is_regex, all_regex_permutations, regex_match and build_regex_tree. The first hill to get over was is_regex, since my thought process would use it in all_regex_permutations and use a very similar method for build_regex_tree.
However, regex_match gave me a lot to think about...and somewhat of a headache. No matter what I did or how I thought of approaching the problem, I couldn't figure out how to write the code so that it did what it was supposed to do in all cases. In the end, I submitted code that didn't work in (as far as I checked) one case, so hopefully I'll still do well. Turns out a classmate of mine had the opposite problem as me so we'll both have a look at each other's code to figure out our problems before the midterm on Wednesday.
Until next time, good luck!
Sunday, 23 March 2014
Sunday, 16 March 2014
Week 9: One big oh!
This week we did work on Binary Search Trees (BSTs) and in particular looked at deletion of data from BSTs during lecture. We also started learning about algorithm performance and analyzing the running time of an algorithm in terms of the size of the input n. We looked at the worst case scenarios of sorting algorithms and found that binary search is almost always more efficient than linear search which is pretty cool.
The idea of the big-oh notation is to give an upper bound on the worst case running time of an algorithm. For example, O(n) means that the algorithm's performance is directly proportional to the size of the input passed to it. Similarly, O(n2) means that the algorithm's performance is proportional to the size of the input squared. Since the big-oh is an upper bound, we can see that we can write things like O(n) ⊆ O(n2). That is, the run time of algorithms that are proportional to the size of the input will most certainly be less than (or bounded above by) the run time of algorithms that are proportional to square of the size of the input. In theory, the idea of an upper bound was easy for me to grasp but understanding it on an example is definitely something I have to spend some time on.
A2 part deux is due this week, so time to get to finishing it. Until next time, adieu!
The idea of the big-oh notation is to give an upper bound on the worst case running time of an algorithm. For example, O(n) means that the algorithm's performance is directly proportional to the size of the input passed to it. Similarly, O(n2) means that the algorithm's performance is proportional to the size of the input squared. Since the big-oh is an upper bound, we can see that we can write things like O(n) ⊆ O(n2). That is, the run time of algorithms that are proportional to the size of the input will most certainly be less than (or bounded above by) the run time of algorithms that are proportional to square of the size of the input. In theory, the idea of an upper bound was easy for me to grasp but understanding it on an example is definitely something I have to spend some time on.
A2 part deux is due this week, so time to get to finishing it. Until next time, adieu!
Friday, 7 March 2014
Week 8: Inherit this!
This week I chose to write about the first part of A2...the regex trees.
To be honest, the first time I sat down to do some coding, I was barely making use of having a superclass even though I knew that the assignment was on inheritance. It took me 3 or 4 instances of copy-pasting chunks of code and only making minor changes to them before I finally stopped trying to plough on through the assignment. Even though I conceptually understood the importance and usefulness of inheritance in creating classes, I wasn't applying it. My code would have most certainly worked, I have no doubt, but then what would have been the point of learning and understanding inheritance if I wasn't going to use it?
In hindsight, it was funny to see the way I thought I had a good grip on inheritance and yet there I was, happily writing lines and lines of duplicate code. In the end (thankfully!), I found a way to make some serious use of my superclass and also learned a bit more about how I should be thinking when I'm trying to use inheritance. I guess what I'm trying to say is that it most certainly pays off to actually try applying the concepts we've learned on our own, even when we think we fully understand something.
On to Exercise 3 this weekend I suppose, so wish me luck!
To be honest, the first time I sat down to do some coding, I was barely making use of having a superclass even though I knew that the assignment was on inheritance. It took me 3 or 4 instances of copy-pasting chunks of code and only making minor changes to them before I finally stopped trying to plough on through the assignment. Even though I conceptually understood the importance and usefulness of inheritance in creating classes, I wasn't applying it. My code would have most certainly worked, I have no doubt, but then what would have been the point of learning and understanding inheritance if I wasn't going to use it?
In hindsight, it was funny to see the way I thought I had a good grip on inheritance and yet there I was, happily writing lines and lines of duplicate code. In the end (thankfully!), I found a way to make some serious use of my superclass and also learned a bit more about how I should be thinking when I'm trying to use inheritance. I guess what I'm trying to say is that it most certainly pays off to actually try applying the concepts we've learned on our own, even when we think we fully understand something.
On to Exercise 3 this weekend I suppose, so wish me luck!
Subscribe to:
Posts (Atom)