tuning performance

I am writing this from Florence during the most exciting trip I've been able to take as a part of grad school. I was fortunate enough that a 7 week workshop in conformal field theory that made a lot of sense for me to attend, chose a beautiful city in a country I had yet to visit. Travelling to surrounding areas will be reserved for the weekends. On weekdays there is a chance to be really productive because the other students and I are surrounded by very intense people.

When we're not talking to these professors and postdocs who have decent offices, the main place for us to work is a room with a window and a twelve seat table. This is not bad because there are usually only six people sitting there. However, this is not guaranteed to stay the case. If one looks at the participant list, there could easily be days when all of the seats fill up. This is where there is room to game the system and I am happy to say that it only required a few lines of code.

There might be other people like me who get nothing out of forecasted temperatures like 21°C, 28°C or 35°C. Do I look at weather often enough to know what 28°C feels like? Of course not. The temperatures I really want to see are relative ones: 2 degrees warmer than yesterday, 6 degrees colder than last Thursday and so on. The problem is that most weather sites blindly assume that future dates are the only interesting ones. They completely erase past dates that you could use for points of comparison. So I went looking for a site that "back-casted" and found Weather Underground. This is a site that I will return to because it has archives of temperatures for many locations. This got me thinking about other hackish things that I do. Maybe someone will find these useful.

Last year, I had two occassions to spend too much of the department's money within the same month. I would guess that the month was either March or April because I had just started playing 2048. And the 2048 craze happened after the Winter Olympics but before the World Cup. On that note I should pause to say that 2014 was a great year especially for a Canadian. I already can't wait until 2018.

Anyway, the fun happened with prospective grad students who were considering UBC physics. During a visit like this, the department pays for a group of grad students to take the visitor out for lunch. With two of these emails that appeared, my reply was in the first batch.

There is a party game called Zombie Dice where you roll dice and try to get as many points as you can without losing all of your health and dying. Green dice make points more likely than death, red dice make death more likely than points and yellow dice are neutral. I played it with some friends awhile ago and realized that it was probably simple enough for me to come up with the optimal strategy.

Just about every game is solvable in principle, but it is very easy to make a game that would take longer than the age of the universe to solve. The prototypical solved game is tic-tac-toe. The prototypical game that is still a long way from being solved is chess. An xkcd comic lists a bunch of solved games so let's see how we can add Zombie Dice to this list.

Since 2004, I've owned a ThinkPad A22m - a laptop that came out in 2001. Much to the dismay of certain friends, I still feel no need to purchase a newer computer. I've often said that this old hardware can do everything I need while still letting me run modern software. However, it now seems like I will have to take some responsibility for the code if I want that to still be true in the future.

Specifically, I am talking about open source ATI drivers on GNU / Linux. The four main video card lines released by ATI (now owned by AMD) have been Wonder, Mach, Rage and Radeon. I don't think Wonder cards have any features that would warrant the development of a dedicated driver but Linux drivers for the other three have been written.

The Radeon driver is actively maintained by software engineers at AMD and some people who work for other software companies. The other two? Not so much. The Rage 128 driver was especially in need of a major update recently. And since my computer has a Rage Mobility graphics card, I felt motivated to start working on the code even though I had never hacked such a low-level piece of software before. Since the effort has largely succeeded, I would like to share my experiences with editing an open source video driver. The learning curve was quite steep and when I first started reading documentation, it seemed like it was written for a different audience. This post is going to be an unadultered attempt to get a completely new reader to catch on to what I did. I'm sure I will later find out that many things written in this post are technically incorrect, but I will not edit them. I want the only knowledge communicated in this piece to be the knowledge that one might reasonably be expected to have after jumping into driver development for the first time.

Awhile ago, my friend showed me Pimp My Gun. This site has a Flash driven app that lets you assemble the weapon of your dreams. It is basically a drawing program that has a library of hundreds of firearm components. There is so much room for customization. I tried it out and came up with the following guns:

So we sent a gun salesman to your mother's house, so you can nag mum to buy a magnum!

As some of you may know, the programming languages I use the most are C and Python. One reason for this is popularity - I want to learn something that will help me edit the programs I use. I also think it's good to know at least one compiled language and one interpreted language. Interpreted languages or "scripting languages" are more convenient in most respects but they take longer to run. I already knew Python would be slower than C but I wanted to see how much slower.

To make the above plot, I used C and Python codes to diagonalize an n by n matrix and kept track of their execution times. Once you get past the small matrices, the trend that begins to emerge is that Python is ~30 times slower than C.