Sunday, 10 November 2013

Entry 4: Assignment 2 Post-Mortem Part Two

I'm going to post a more interesting diary later, but first I'd thought I would touch on an experience I had during assignment 2. I think I learned something interesting here about analyzing my own code, and also about the prudence in changing one's approach, and in thinking about the problem before one starts, instead of getting in a mess later.

First, an overview of the problem. In part 2 of the assignment, we had to write a function to match strings against regular expressions. The solution seemed pretty simple for me to grasp: take the regex, split it at the position of the the the top-level regex operator(the one on the first nesting level) and then partition the string the same way, and then match. I made a couple of mistakes right of the bat. I had a gut feeling that it would be easier to work with regular expressions in string form than it would in RegexTree form. So I coded up a neat little function to convert them. In and of itself, writing that function didn't waste too much time, but it started me down what in retrospect was the wrong approach to the problem. It actually was MUCH easier just to work with the RegexTrees.

After coding up that function, I hit the second problem, where once again I took the wrong fork in the road. After figuring out to handle the regexs, I had to decide how to handle the strings. They needed to be split in certain ways, according to the regex symbol. This was tricky, for obvious reasons, as regex strings of only 5 or 6 characters could correspond to strings hundreds of characters long. Somehow, I created some extremely convoluted code to handle these situations for bar and dot operators. The trouble really began when I turned my attention to the star operator.

Attempting to partition the string precisely here was nearly impossible, but that didn't stop me wasting several hours on an attempted solution. I did find a much better approach in the end- namely splitting the string into every possible configuration and seeing if one of them matched. I feel as if I learned some important lessons here:

1. Think before you code! Despite the fact that this in the briefing to every assignment and exercise, I didn't follow this rule here, and paid the price in the form of a lot of wasted time. The first approach I chanced on was not the right one, and I think I could have avoided this if I had put some more thought into it.

2. Don't be afraid to change your approach. This was my second problem. I leaped into the problem without looking, but I could have fixed that if I gave up sooner. Instead, I didn't want to feel like I was quitting the problem, and so pressed on to my detriment. It would have been far better to cut my losses and switch approaches, even if I have to throw out some of my code.

2 comments:

  1. I completely agree with your analysis, I did the same thing as you in many parts of the assignment including the part where you wrote a function to convert the trees into strings. In the end the damage had already been done. More detailed planning would definitely lead to better results in the future for me.

    ReplyDelete
    Replies
    1. I bet we're not the only ones! I think this is a pretty natural human tendency when it comes to things like this. I'm going to force myself to at least take a deep breath in the future before jumping in.

      Delete