Finished CS106B, just in time to begin “Start Up Engineering” on Coursera. I had alot of trouble finishing this final exercise, because it was the last one, and my attention had already moved on somewhat. I’m definitely going to have to start using this stuff for real now. I’ve done more than enough exercises. This isn’t the whole thing but I’ve got a Github account now and will put the whole course up on there asap…

It feels good to have written a compression program! One more exercise to go and CS106B is done…

This was all about debugging. Working out how to do it doesn’t take very long. Some of the bugs, once I’d found them, were bemusing. One of them turned out to be a bug in the map class provided by Stanford. Another was simply about the way I was declaring an addition to a string. Both the way I was doing it and the way that worked mean the same thing, as far as I’m aware. But I got into it, you just have to accept that if you get ahead of yourself, you’re probably going to have to end up checking every individual part for bugs. On the evidence of this, test-driven programming makes sense- so that you know that every function or class that you add does what it’s supposed to, before you add it. It turns out that a pseudo eof is only necessary if you aren’t using the frequency in the root node to decompress in a loop. So if you were to decompress recursively. But I found that had weird bugs too- I suspect due to bugs in the class libraries.

Mood break. I’m in the middle of Huffman Encoding, which is frustrating, not because it’s difficult to think through, but because the bugs are silly. A friend of mine told me, nearly a year ago when I decided to learn to program, that “programming is easy, debugging is hard”. That’s very true. I’m now on my second week doing this, off and on, which is the longest I’ve ever spent on a single program. I’m building little programs just to eek out the junk from little parts of my program. Which makes me think that I have to have some counterpoint. I’ve been wondering how to produce physical objects for a while, and the amazing Ashley Bickerton is much on my thoughts right now;

Here’s the heap implementation. I think I’m going to have a go at binomial heap too. This one was tricky because of the way merge is set up as a static member function. I figured expandCapacity is expensive, so I created a new instance and called expand capacity to a big enough size, on the empty array. Then copied one and two into it before heapifying it. Whether that would actually make any difference in speed, I’m not really sure.

So this is what’s happening with the Immersion project! I’d like to throw it open for participation, with anyone who wants to contribute. I’m going to publish a book and continue to do exhibitions on it, and I’d like the collaborative element to be part of that. If you click through to the Kickstarter page, look at update #1. Within two days of launching we’ve already had a very cool idea about how to use the proposed site in a way that will create work that I simply wouldn’t be able to do on my own. I’m excited! What with the programming I’m doing, I’m becoming less and less interested in actually shooting work (I will continue to shoot Immersion till the project finishes). Instead it’s become much more interesting to think about ways to create participatory and more engaging projects…

The rewards for the project include the book, a collector’s edition of the book, and limited edition prints.

5. Mysterysort5 is Bubble sort. It’s slow, does well on sorted, badly on reverse sorted, as you’d expect.

My adjusted algorithm is below, but I couldn’t get #include cmpfn.h to load in XCode. So I couldn’t use the OperatorCmp function. So this algorithm only works for integers, chars etc, it isn’t fully generalized. That’s a trivial task though. I’ll see if there’s any alternatives I can use. All I did was randomize the selection of the pivot and then swap it out with the first cell of the vector, which is treated as the pivot (the rest of the algorithm is unchanged). It’s very simple and very effective. The adjusted quicksort remains much faster than any other algorithm on data of reasonable size (except for the original quicksort, on unsorted data), and quicksort’s normal worst-case scenarios become blisteringly fast. It remains NlogN. It’s only possible weak point is repeated bad luck on the randomized choice of pivot. That, however, is extremely unlikely since the pivot is chosen at every level of the recursion.

If anyone knows how to get #include cmpfn.h working on XCode, or if there’s an alternative, please email me! The libStanfordCPPLib is loaded…

It says on the assignment brief for this exercise to properly decompose the Boggle program, before starting work. Of course I didn’t. By this stage I was getting cocky and felt like recursion was getting easy. This problem has the capacity to produce hard-to-find bugs if you don’t prepare. My mistake was passing the x and y of the next square/current square, as a parameter. That doesn’t work- much better to get x and y from whatever you’re storing the path of tiles in. They tell you to split the execution between human and player turns, which I did, but I had the computer turn call two of the same functions. The first time I’ve re-used functions! I think if I’d done it flat-out it would have taken me maybe 3 days. Which gives me quite alot of respect for those kids at Stanford! Apparently the CS106B page has changed since I linked to it, so someone asked me to send the course files I’m working from. I’ll try and post them on this blog soon…

Unexpectedly epic. Probably has post Christmas flab on it. I like the way the Stanford exercises are always hooked up to a graphics window and carefully thought out to make the whole thing very visual. Recursive backtracking is quite tricky but amazingly satisfying to get it going. The process is definitely becoming like building. Not that I’ve ever built anything, except for some plastic models when I was a kid. Which I promptly set fire to, nine times out of ten.

Another quite enjoyable one. The equivalent to printing out values as a way of debugging/trying out ideas, in recursion, seems to be to write pseudo code. Never really did it before this exercise and it helps enormously.