Wow. Been over a year since I've written anything here. Life has been pretty good of late. Helen and I have bought a condo in Belmont (Boston area) and moved in. I love all the extra space. The other members of the condo association could be more pleasant to deal with. One lady has been downright rude. She has no communicaiton skills and becomes enraged over the simplest things. Happily, she appointed her sister to take her place. We can at least talk and argue in a reasonable manner with her sister. Things are much better than they were before. Since the new lady was appointed, we agreed to replace the roof which is about 30 years old and has been leaking into our bathroom ever since we moved it. I can't wait until the roofers begin work. Now that the association is easier to deal with, Helen and I have been having fun buying furniture and planning projects to make our place even nicer. We want to add a closet in the hallway and add shelves in two existing closets. I want to make a wine rack in the basement. Right now, I just store wine bottles in the boxes I get from Wine & Cheese Cask.
I'm working for the summer. Consulting for a cool company called ITA Software. Btw, if you're reading this, are a good lisp or C++ hacker or are an XML expert and wouldn't mind working in Cambridge, MA, send your resume to firstname.lastname@example.org. ITA is revolutionizing the airline ticketing industry. Many airlines still use mainframes and (get this) assembly code to process tickets, find flights for customers, etc. Most airlines would have trouble finding you their cheapest ticket from Boston to L.A. simply because there are so many options (combinations of flights, booking codes, etc.) and because their software isn't meant to actually search for a low price ticket. ITA has written a collosal library of software for dealing with the day-to-day aspects of airline ticketing. A big application is low-fare searching. See beta.itasoftware.com for a sample. There are also tons of other aspects for which airlines and airline-related companies need software.
Anyway, I'm working on a machine learning-related project for them. It has to do with Poisson processes, something which I learned a lot about in a class I took in the spring. I've also been coding a lot. I'm becoming pretty familiar with all of the ++ aspects of C++. It's amazing that gcc still has a ways to go before it is compliant with the standard. readsome() will be a nice function to have. I'm surprised at how easy C++ is to deal with once you know most of the ins-and-outs of the standard libraries. 'map' has made my life a whole lot easier. 'string's are nice, although they'd be nicer if everything used string's rather than char*'s. I'm surprised that there isn't a resizing-vector in the standard library, though. Well, at least it's easy enough to derive such a class. Anyway, after spending the first month or so hating every bit of C++, I now mostly enjoy using it. The project that I'm working on is coming well. I'm nearly finished with a protype that will probably go into use RSN. I just need to evaluate it and make sure that it does better than what was used before.
On the school side, I've been working on my master's thesis. I've been learning a bit about Bayesian statistics and how to determine the probability of a new object from training data by integrating over all possible parameters rather than estimating a "best" parameter (via MAP or ML). I also think that I've been learning how to do research. In the past, I've tended to think up a "cool" idea, phiosophize about it, analyze it, draw conclusions about it and then do experiments with the idea. I've learned that it's better to first test the idea. Once you get the idea, you should immediately implement it and play with it. See what it does. Try to think of ways to further and expound on your original idea. Once you've seen the idea in action, then it is time to philosophize and to draw conclusions. The same is true for programming. When I write code, I often try to scrutinize it to try to catch bugs before I run the code once. I do find bugs this way sometimes, but I spend (waste) a lot of time looking over code. Occasionally, I tell myself to write and immediately test once the code compiles. I find that I more quickly find and fix bugs this way and I end up with working code more quickly. I guess I'm just re-learning what Microsoft learned long ago: testing is a necessary evil---the quicker you begin testing and the more you do, the better the end product.
Anyway, the master's thesis is coming along. I have most of it written. I need to fill in the content holes and compile a full first draft this weekend. I'll be spending the next few weeks polishing up the writing and presentation.
Master's thesis and ITA have kept me quite busy of late. It's almost like having two full-time jobs. The fall should be nice. I plan to slack off and take it easy for at least a few weeks. Everyone needs their down-time :)