Journal
Week 1 May 13-17
I didn't get a whole lot done this week. It was mostly just getting used to the whole idea. Amy got me an office with two officemates working on their PhDs to work in. Amy gave me a lot of papers to read about TAC and RoxyBot and a few other agents. A lot of the things in the papers about AI theories I didn't understand very well. They used a lot of notation that made me wish I had brought my notes with me from my MATH 241 course. Amy told me that one of the things she wanted to do to improve RoxyBot was to implement a threaded version. I leaped at that since one of the comp sci courses I had just finished at Bucknell dealt with threads and it was still fresh in my mind. I started working with the RoxyBot code to try and put threads into it, but I hit a major snag when it would give a segmentation fault immediately upon running. I figured out that it was the lpthreads library causing the segfault. I figured it was a problem that Amy or another professor would be able to figure out since I wasn't very knowledgeable about libraries or threads in C++ (I had done threads in Java, but not in C++, which was the language RoxyBot was written in). I asked around but nobody seemed to know how to fix it.
Week 2 May 20-24
This week was a lot like last week. Once again, I didn't get much done because I was stuck with the lpthreads problem. Nobody seemed to know how to fix it and nothing I tried worked. I was getting very frustrated. I went home early a few days because there wasn't anything for me to do besides beat my head against a wall. I read up a little on Python because Amy had mentioned wanted to write a script in either Perl or Python. I wasn't sure what she wanted to do with it, so reading was all I did.
Week 3 May 27-31
I discovered this week that the lpthreads caused a segfault only when I compiled on a linux machine. The computer in my office was a linux machine, but I could use ssh to work remotely on a Solaris machine. I got the threads version to compile, but there were a lot of bugs and it never really ran right. Amy also said that over the weekend she'll do a code overhaul so that it'll be more thread-friendly. The way it is now, it uses lots of global variables which could get us in trouble if different threads try to access the same variable at the same time.
Week 4 June 3-7
Amy re-wrote the code, fixing a few bugs and making it into a series of functions that take local variables as parameters instead of just editing global variables. I took the new code and re-wrote my threaded version using the new functions. She also told me exactly what she wanted with the Perl or Python script. She wanted me to write a script that would test out RoxyBot with different parameters so we could find out what parameters worked best. I started working on it in Perl. What it should do is when it's finished is play eight RoxyBots (the number of agents in one game), four of one parameter type and four of another against each other, then parse the log files of the agents to get their scores and average them over a number of games. So far all it does is play a few RoxyBots on the server and nothing else.
Week 5 June 10-14
I worked a bit more with the script this week. It's pretty much done. I started running the tests. Amy asked me to try and debug a few problems in RoxyBot. I tried to put it off because I didn't really feel confident that I knew my way around the program enough to debug it. But after I finished the script and did as much as I could with threads I really didn't have anything else to do. I eventually found the infinite loop Amy wanted me to debug and she fixed it.
Week 6 June 17-21
The qualifying rounds started this week. I did a lot more debugging. I got to know my way around the code really well. I surprised myself at the number of bugs I found and fixed. Amy called me an "expert debugger" at one point. It sounds like it should be tedious, but I actually had fun debugging the program. I never really understood a lot of the theory behind RoxyBot, and when Amy talked with Maureen, the other student working with us with the Mentor Project, about her work and what she was testing most of it would go over my head. I don't think AI is really for me anymore. I enjoy just working with the code. I think software development is more my style, and if I were going to go to grad school that's what I would specialize in. I kept running the script all week.
Week 7 June 24-28
The qualifying rounds ended this week. They decided to scrap the scores from last week because of server problems. We had been bouncing around 5th place before the reset and our scores dropped a lot afterwards. I guess we were taking advantage of some server bugs. RoxyBotII finished in 14th place and RoxyBot finished in 15th. I was very surprised because my tests had shown that RoxyBot's algorithm should score much higher than RoxyBotII, yet they scored right next to each other. I wonder if it's because I tested on an older version of the TAC server? Amy told me that since Brown was moving from Solaris machines to Linux that the solver RoxyBot used had to be moved to Linux since they were letting the license for the Solaris version expire and getting a new Linux license. I'm really not looking forward to having to get the threads working for Linux. I'm afraid I'm going to end up bashing my head against the wall for another two weeks only to find out that we can't get the threaded version working and all the work I did on the threads was for nothing. Amy got a little more specific on what she wanted threads to do and I finally got the threaded code working for Solaris, though. It's three threads, one to ping the server, one main thread, and one thread to bid on entertainment tickets (the rest of the bidding happens in the main thread). Seeding rounds start next Monday. I won't be here next week and neither will Amy for a part of it, so I told Maureen how to restart RoxyBot in case it should stop playing for whatever reason. It won't really matter what heat we place into in the long run, but nineteen agents will go into the seeding round and only sixteen come out. We can't afford to get so many zero scores that we'll drop down into those last three.
Week 8 July 8-12
The seeding rounds ended. RoxyBot finished in 8th place, putting us in the second heat for the semi-finals. We won't be actively competing until the 28th, when the semi-finals and finals take place. I won't be here at that time, but I'll be sure to watch the website from home and cheer Roxy on. ;) Amy told me in the beginning of the week that if we wanted to use a threaded RoxyBot in the finals that we should have a running version by Friday. I was surprised when it compiled and ran right away on the linux machines. It was still very full of bugs, though. When I finish with it, it should have four threads, one main thread to do all the calculations, one thread to ping the server, and three threads to bid on the three different auction types.
Week 9 July 15-19
It's starting to get down to crunch time. Only one week left now. Amy gave me a final list of eight tests to run and I re-wrote the scripting thread to accommodate all of the tests. I ran them all week, but Amy made a lot of changes to RoxyBot during the week, so we'll have to run them again this weekend to get up-to-date results. I think I finally worked out all the bugs in the threaded version. The partially-threaded version I was using for debugging was consistently outperforming the non-threaded agent I was playing it against, but something was wrong with the fully threaded version that made it bid on too many flights (one of the most serious mistakes RoxyBot can make). I think I figured the bug out and made the changes, but I didn't get a chance to test it out because at the last moment we found some infinite loops in the algorithms we wanted to run tests on over the weekends. I narrowed down what tests the loop was in but I didn't have enough time at the end of Friday to debug the algorithm. Amy will run the tests over the weekend so she can keep an eye on them and try to debug the loop. Those tests should tell us the final parameters we'll use when competing and we'll run those parameters when we test the threaded against the unthreaded version next week.
Week 10 July 22-26
The project's over now. RoxyBot didn't get past the semi-finals. I wish I knew what went wrong with it. Over the weekend Amy implemented a new algorithm that calculated the bids separately so it could take advantage of the threaded version. It would first figure out what flights it wanted and would bid on those, then figure out what hotel rooms and entertainment tickets and bid on them. Amy gave it to me untested, but it seemed to work fine. I worked the threaded version to use the new algorithm, and that worked fine, too. It worked better than the unthreaded version and I was seeing pretty high scores. I was confident it would do fairly well. Maureen and I implemented a new estimation algorithm for hotel rooms based on the data sics had collected from the seeding rounds. It was different than what we had been using, but not necessarily better. Amy had an idea on how to improve it and Maureen volunteered to try and implement it while I continued to work on threads. I don't know if she actually got it working before Roxy played in the semis. I continued to run my script all week to test the different algorithms and version combinations that Amy gave me. I wrote up some documentation for the scripts, added the option to drop the lowest x scores, implemented more parameters to increase the user-friendliness, and made sure Amy understood the documentation and knew how to use everything I wrote. At the end of the week, I turned the scripts over to her to continue the testing over the weekend. My last task was to implement a new timing algorithm Amy thought up to work with threads and the new separate flight bidding algorithm. I think this is where Roxy took a turn for the worse. I worked on this for the last few days. I wrote the code for a finite state machine to run the timing fairly quickly (it made more sense to me as a finite state machine than what Amy had originally implemented), but debugging it took the rest of the week. Amy had made some changes to the flight algorithm while I implemented the new machine, so I was debugging her algorithm at the same time. In the end, I left it with a segfault when it was compiled with the fast option. When it compiled normally there were no errors, but Amy wanted to compete with it in fast mode. I had no idea what was causing the segfault. I stayed an hour and a half later than normal trying to debug it, and I would've stayed longer but I was leaving early the next morning and needed to pack. I gave Amy everything I had figured out so far about the segfault and crossed my fingers that she would be able to fix it over the weekend before it went to the competition. Even when it didn't segfault, though, I wasn't seeing the same high scores I had before I implemented the new timing. I still don't know what caused the segfault or the drop in scores, whether it was my code or Amy's ideas. I suspect it was my code, but I did as best I could in the time I had.