Final Report
This summer I worked with Amy Greenwald on RoxyBot for the 2002 Trading Agent Competition. I helped debug the program and implemented a threaded version. The final version I implemented had five threads, one to ping the server, one to do the bulk of the calculations, and three to bid on each of the different kinds of auctions, flight, hotel, and entertainment. The main calculation thread was a finite state machine that implemented a new timing algorithm with three phases. In the end, the threaded RoxyBot I made didn't perform as well as I had hoped. I was confident in the main structure of the five threads. I was sure that there was no danger of deadlock, that the critical sections of each thread were sufficiently protected, and that the threads were properly synchronized, but I felt like I rushed it in the end. Instead of implementing the new timing Amy gave me, I think I should have left it with the old timing. It performed much better with the old timing, and I'm not sure whether the problem came from the timing itself or my implementation of it, but something went wrong. I was disappointed in the project, but I think I took home a lot of experience and should be able to learn from my mistakes.
A more successful project was the three scripts I wrote in Perl to run tests and collect data on different versions of RoxyBot with different parameters. I had no prior experience with Perl and very little experience with any other scripting languages before this summer. The final scripts I wrote were very robust, easy to use, well documented, and outputted data in a readable format. The first script ran for x number of loops and ran the games it found in a .gms file specified by the user. It collected the data and added it to a .scr file where the scores of the games run were kept. It called the second script at the end of each loop, which parsed the .scr file and saved the averages and standard deviations of the different games played in a .avg file. That script then called the last script, which parsed the .scr file and saved the information in an easily readable format to a .rslt file. If the .avg file or the .rslt file was corrupted or deleted, the user could run the appropriate script to re-generate the file or files. All the parameters were optional, and appropriate defaults were in place, so all a user needed to do in normal circumstances was place the games she wanted to play in a file called experiments.gms and then run the first script with no parameters.
In the end, RoxyBot only made it to the semi-finals. I had hoped we'd make it all the way to the finals, but I still think I had a productive summer. I learned a new language and had the opportunity to apply the knowledge of threads I had just learned the semester before to a larger project and a different language (I had worked with threads in Java, but RoxyBot was written in C++). I also had the experience of working with a team on a large program. Previously I had only worked on small or medium-sized programs, and only once or twice in teams. I decided this summer that I'd like to apply to graduate school to get a masters in software development or a similar field, though I'm probably going to start my career first and go to school at night so I don't end up going too far into debt. I'm glad I had the opportunity to participate in this program and my only regret is that I hadn't found out about it sooner.