Monday, 17 March 2014

Week 9

Exercise 3 went by rather easily as long as one thinks recursively, although it took a bit of thinking, particularly in the case of a two-element tree. In such a situation, I chose to resort to a rather a bit convoluted, semi-manual strategy.

Assignment 2 part 2 also ended up a little convoluted when it came to working with bar and dot regexs (is that the proper plural?), although it was also not too complicated. It helps that two totally separate functions have essentially the same structure however. In total, I spent about 5 hours on it.

Monday, 10 March 2014

Week 8 - No Longer Considered Late (by definition)

From now one, works posted on Monday of the week after will no longer be considered late, by my new definition of the term.

The focus of the past week has been an part of an assignment based around the creation of a tree structure, and an exercise to create and analyze trees. Both went on without considerable difficulty. The tree exercises did however, emphasize the importance of thinking about recursive problems recursively, rather they trying to get a closed solution for them.

Monday, 3 March 2014

Week 7 - Recursion (Slightly late again)

The topic of this week is recursion. To sum it up simply, recursion is the process of calling a function within itself, although it can more accurately be described as repeatedly performing the same action on a certain object. In computer science recursion and loops are generally seen as two ways of doing the same job in most cases. Unlike with loops however (unless somebody uses "while True"), one must be careful with recursion to make sure there is a stop condition in the function. If one doesn't, they run the risk of running out of memory space, which, suffice to say, may cause issues. For some situations, such as when, one is going over a nested list of unknown depth, recursively going over the list is far simpler and more efficient than using loops.

To recursion, if I need to find out the minimum number of moves needed to complete a Tower of Hanoi game with x number of blocks and 4 pegs,

def best_split(n: int) -> int:
    """Determine the optimal value to split at."""
    choices = [i for i in range(1, n)]
    num_moves = []
    if n == 1:
        return (1,1)
    else:
        num_moves = [(2 * best_split(n - i)[0] + 2 ** i - 1) for i in choices]
        optimal_i = choices[num_moves.index(min(num_moves))]
        return (min(num_moves), optimal_i)

Note that this function also returns the best value to split the tower at, but that is largely irrelevant to the current discussion. As can be seen, I call the function within itself at line 8. I also have an appropriate stop condition where the function will stop running at line 5. Both are necessary for a recursive function.

Recursion has, at this point, permeated so much into my life that I think about iterative problems recursively.

Sunday, 23 February 2014

Week 7 - Nothing to report

Reading week. Have a test and assignment coming up, but that can wait. All quiet on the western front. Got an interesting question from a younger friend regarding breadth-first searching though. Searching it up, it seems rather pointless. Will need to investigate further.

Saturday, 15 February 2014

Week 6 (apparently)

The topic once again falls back to recursion. More specifically, Assignment 1. After experimenting with a few different ways to solve the Tower of Hanoi with four stools in the fewest moves possible (with varying levels of success), I managed to find, with great difficulty, the minimal number of moves and the optimal split value i recursively. Unfortunately however, in this configuration, I was not able to actually move the cheeses in any stacks totalling more than ten blocks without attempting an illegal move, something I was able to accomplish with more basic splitting methods. It certainly did not help that my computer decided to die on the due date, but fortunately I had already submitted the files beforehand. And people wonder why I hate computers....

Monday, 10 February 2014

Week 5 - A bit late

As mentioned, this update is slightly behind schedule thanks to a preoccupation with the Tour of HanoiAnne Hoy assignment. While not complete yet, this assignment has been the object of particular annoyance for the past week or more, and I have not yet even worked on the recursion part, which will probably actually be easier, interestingly. One positive product of this however is that I finally decided to make use of doctest, and to good effect. On the other hand, I really wish instructors gave better descriptions on how to use code that's provided. I spent about an hour messing around with the GUIController and trying to debug my own code, not realizing that I was supposed to click on the "stool" rather than the space above it in the interface.

Sunday, 2 February 2014

Week 4

Recursion is the hot topic this week, but for the large part, that's a topic for another time. I already know the basics from beforehand, and I would say it is fair to say that recursion is surprisingly easier to understand than it is to explain without the use of aids.

So, without further delay, rather sure than talk about recursion, I will talk about errors and exceptions. The basic concept is rather simple, plan ahead for errors that might occur, and deal with them. That said, it took me quite a while to figure out what Exercise 2 meant when it said to raise an exception implicitly, even though, as it turned out, I had done it that way all along. Using unittest to check if an exception is properly raised was also an annoyance during the lab, thanks to the not entirely intuitive way that assertRaises works, and the Library not being entirely clear on that.