23 June 2010

Battleship Chronicles, Part IV: Over 9000

The basic idea for Over 9000 was inspired by a TopCoder marathon match, except that in their variation multiple shots were fired in a single turn and you were only told which ships were hit without knowing which shots were the hits, and board sizes could be much larger. I was curious to see how it would do and decided to implement it with a few modifications described below. For those who are interested, the problem statement can be found here and the editorial can be found here.

Over 9000 essentially uses a brute force strategy to choose the next place to fire. For each possible ship, try to place it on every possible location. If you can place it, increment a counter of every square the ship is on by 1. Thus, if we assume all layouts of a particular ship are equally likely, we can compute the probability that a given ship will be on a given square simply by dividing by the total number of possible layouts. Consider the example grid below, where 0 represents a known miss, a number from 1 to 5 represents a known hit, and x represents an unknown square (we will consider a smaller grid for simplicity):

Suppose we are considering ship number 3, with length 3. Here are the 7 possible locations:

3330x xxx03 xxx0x xxx0x xxx0x xxx0x xxx0x
4440x 44403 44403 4440x 4440x 4440x 4440x
xx0xx xx0x3 xx0x3 xx0x3 3x0xx xx0xx xx0xx
x5xxx x5xxx x5xx3 x5xx3 35xxx x5xxx x5333
xxx0x xxx0x xxx0x xxx03 3xx0x 3330x xxx0x

If we look at the top left corner, there is only one configuration, so the probability is 1/7. However, the middle of the right column has probability 3/7 and will thus be more likely to contain this ship, so if we were only trying to find this ship then it would be the best place to fire. However, we have five ships to consider, not only one, and we would like to find the probability of a given square containing any ship using our probabilities for each ship. We will have to make one more assumption to do this and assume that the ship locations are independent of each other. Of course, this is not true due to the constraint that no two ships can overlap, but it does give a good approximation. If you look at the example grid, you will notice that there is a hit on ship 5, making the surrounding locations less likely to contain ship 3.

To compute this probability, we cannot simply add the probabilities of each ship, as this will count some cases twice. Instead, we can compute easily the probability that there is no ship on a given square, as we can simply multiply the probabilities for each ship of that ship not being on a square due to our independence assumption. Since p(not X) = 1 - p(X), then if we define p(n) to be the probability of ship n being on a given square, then the probability of finding any ship on a given square is equal to
1 - (1 - p(1)) * (1 - p(2)) * ... * (1 - p(5)). Once we get the probability for each square, then we can simply pick the square with highest probability that we have not already tried and fire there.

Over 9000 also includes some modifications to this strategy to account for the assumption that all locations are equally likely. This is of course not the case, especially since many people kept the original layouts sent with BruteForce or created their own. To counter this, every square was weighted and when the probabilities were computed, they were multiplied by the weights before determining the maximum. Over 9000's weight grid was based on the observation that human players preferred to place ships on the sides, and thus it gave the squares on the sides a higher weight than the others. In addition, Over 9000 added a small random number to the final probabilities, which had the effects of breaking ties and creating more interesting games, though it likely decreased performance slightly due to non-optimal behavior, as only one shot is fired at a time. However, this did have the positive effect of having no definite worst-case enemy ship placement, as Over 9000 would no longer be deterministic.

There are still some improvements which can be made, however. One simple improvement is to keep track of the games you play and increase the values in your weight grid as you get hits in squares, giving better results against people who play a small set of layouts. Another improvement which can be made is to consider multiple ships at a time instead of one ship, which will help offset the independence assumption. Ideally, we would consider layouts of all ships at once instead of placing single ships, but this would of course take up too much time in the early stages of the game when there is little known information.

Bob uses the same strategy, except that Bob uses only the information that a square was a hit or a miss. Also, Bob does not use either of the modifications described two paragraphs ago.

With regard to ship placement, it would usually make little difference how your ships were placed as a whole, though it was often possible to look at other programs and determine the worst case placement against their program.

The code for Over 9000 is attached and we highly suggest that you read it. We have commented most of the lines and tried to make it not too difficult to understand. We have also implemented a random ship placement function and we recommend you look at the coding techniques used, especially if you had trouble implementing or were not sure of how to do this.

22 June 2010

Battleship Chronicles, Part III

Original email sent to CompTeam members:

Thank you for showing interest in computer science and participating in the Computer Team elective or joining the mailing list for the past trimester. I hope you learned something new, interesting, and worthwhile from the elective, whether it be a new algorithm, that USACO is not trivial, that Battleship is fun, but even more so when visualized with fitting sound effects, that student-run electives work, or that Dr. Nevard loves dark chocolate. Most importantly, I hope you all had fun. I know that working on USACO training or listening to lectures can get quite boring; this is why we decided to do a project for the end of the year.

After about a month of work on the final project, Battleship, we finally get to see the skills of each and every one of you as problem solvers and computer scientists. From reading your code to watching your programs battle each other on screen, we have gotten a fairly good estimate of your skills in a real-life task. My expectations were in line with the tournament results.

The tournament was run on a homebuilt machine with the following specs: Intel Core 2 Quad Q9550, 8GB memory, 100GB disk, NVidia 8800GTS 320MB running Ubuntu 10.04 LTS. Each program played every other program 399 times. The following programs were included in the tournament:
  • AndrwsBtlshpPgrm v3.0 (Andrew Cai)
  • Colonel (Jie Guan)
  • Tertius (Alec Benzer, Mark Fayngersh, Vikram Jayashankar)
  • Slayer V5 (Nick Bevacqua)
  • Over 9000 (Sam Fingeret)
  • Bob (Sam Fingeret)
  • BruteForce (Sam Fingeret)
  • Random 2.0 (Sam Fingeret)
  • Rofl Copter (Matt Lotocki)
#NONAME (Alex Zhu) was not entered because it was less than 50 lines long. Alex Zhu was disqualified by teachers' discretion. His program just shot at cell `A1'.

Zumwalt Mk II (Jonathan Beekman) was not entered because some opponents' ship placements caused it to hang.

Ari Jidai (Jonathan Sorce) was not entered because some opponents' ship placements caused it to crash.

With that being said, let me present the tournament rankings:

nonitalics = benchmark programs; they are not allowed to win the tournament

=== RESULTS ===
1. Over 9000 won 2857
2. Colonel won 2551
3. AndrwsBtlshpPgrm v3.0 won 2536
4. Slayer V5 won 1902
5. Bob won 1794
6. Tertius won 1419
7. BruteForce won 592
8. Random 2.0 won 479
9. Rofl Copter won 234

Congratulations Jie Guan for winning the first annual Battleship Tournament! Also, props to Andrew for putting up a tough fight.

Here are more statistics:

=== ACCURACY ===
Over 9000 : 37.11636673573047%
AndrwsBtlshpPgrm v3.0 : 33.74789674827501%
Colonel : 32.46263314180419%
Tertius : 29.055394377209023%
Slayer V5 : 28.02107767763948%
Bob : 27.673535550917084%
Random 2.0 : 17.22408350601313%
BruteForce : 17.080802952490675%
Rofl Copter : 9.710122203384847%

And even more statistics:

1 = AndrwsBtlshpPgrm v3.0
2 = Colonel
3 = Tertius
4 = Slayer V5
5 = Over 9000
6 = Bob
7 = BruteForce
8 = Random 2.0
9 = Rofl Copter

1 2 3 4 5     6     7     8     9
1  0 220 318 308 124 375 398 399 394
2 179 0 379 389 56   351 399 399   399
3 81 20 0    29 50    63   381   396   399
4 91 10 370 0 67   168   399 398   399
5 275 343 349 332 0 377 399 399 383
6 24 48 336 231 22 0 398   398 337
7 1 0 18 0 0 1 0   252   320
8 0 0 3 1 0 1   147     0 327
9 5 0 0 0    16 62    79    72 0
We will be sending out an explanation about Over 9000 in the near future, by popular request.

Again, thank you all for participating in the tournament and in the elective. We hope you found it to be interesting and more helpful/fun/challenging than your normal computer science classes. I won't be sending out many emails from now on; I expect one or two more regarding the future of Computer Team. Enjoy the remainder of the year!

The Visualizer source code and dependencies are located here: http://github.com/shewu/Battleship-Visualizer

21 June 2010

Farewell CompTeam

Hello all,

Wow! It has been a great first year for BCA Computer Team. You all deserve a big pat on the back for shaping the elective into what it is now and deserve many thanks for your involvement and contributions. Hopefully the elective has fulfilled its intended purpose: to present challenges in computer science to further current knowledge. Please do not feel discouraged by USACO training and the contests, they were meant to be tough and non-routine. Battleship was meant to be a relaxing break from the training problems; hopefully it was a good application of algorithmic programming, data structures, and most of all, problem solving in a real-life programming job.

The real lesson to be learned from CompTeam is to create opportunities for yourself. Don't complain about the teachers; just finish their work quickly so you have more time for your own endeavors. There is a plethora of fresh material waiting: USACO, TopCoder, research, and even projects. The last option is most definitely possible. I'll give you two examples. At the end of junior year, I wrote a minesweeper clone, LOLsweeper, in two days using Java. This year, Mark Fayngersh, Alec Benzer, Vikram Jayashankar, and friends wrote a full-blown iPad game, Blob Defense in about a month using Objective C. Sure, this sounds intimidating at first, but if you are willing to take the time to learn cool techniques, languages, and coding paradigms, you most certainly will get a phenomenal product and you will be impressed at what you are capable of. So when should you start? NOW!

Last but not least, since the elective is in its infancy, I would like to present my expectations for CompTeam's future. I will officially empower Alec Benzer as 2010-2011 Captain at 12:00PM on 24 June 2010. This does not imply that he is the one doing everything, though he is the one managing logistics. Remember that this is CompTeam; it has been successful for the past year because of you, the individual. My stepping down means that I will not be dictating the future of CompTeam. Keep the team alive, make it a tradition, and hopefully it will be recognized as a competent team. Attract freshmen and everyone who wants to pursue computer science or wants a challenge in problem solving with computers. Do a mixture of lectures, contest problems, and projects. Host a game tournament, party, and give out prizes. Share lectures, material, knowledge and put them on a website or central repository. Get parents involved. Learn. Have fun. Make new friends.

I must reiterate myself again: don't let teachers limit your potential. Reflect on the accomplishments you made in CompTeam. That was all you. If you realized that compsci isn't your passion, keep looking. As Steve Jobs said in his Stanford Commencement speech, "Don't settle until you found something (or someone) you love. As with all matters of the heart, you'll know when you find it."

That's all for now. Keep in touch! Feel free if you have programming questions :)


Battleship Chronicles, Part II

While the contestants were working on their programs, Sam and I worked on the Visualizer. We decided to work in a linear fashion, which probably was not very efficient. Then again, neither of us felt like writing an API or outline. We agreed that Sam would take care of the underpinnings and I would do the graphics and interface.

Sam started out with a backbone from another TopCoder visualizer. He slowly built upon it, changing, adding, and deleting functions as necessary. After a week's worth of work in class, during frees, and at home, Sam had a program that displayed the ships as colored blocks. We showed this on 28 May 2010 and wowed the class. BruteForce, Random 1.0, Bob, Over 9000, Slayer (Nick), and ./battleship (Alec, Mark, Vikram) participated. We were confident that people were awed by how fun the Battleship tournament would be.

Following that Friday was Memorial weekend. This was basically my only free time to substantially revamp the program. Coincidentally, I received my beautiful Dell Ultrasharp U2211 21" screen, of whose widescreen-ness I took advantage to do the graphics for the ships.

the second window is 1px higher than the others >_<

Sound effects were secondary, since those could be trivially found on the internet. I settled on a frog croak and glass breaking. After about a day's worth of work, I can say that I have made some progress.

I then sent the two screenshots to two folks, who then gave me comments and suggestions. Both of them thought it was phenomenal compared to the original. One of them suggested using a top-down view instead of a perspective view of the ocean.

In the meantime, the competitors kept on working on and sending me their programs. Sam assisted me in debugging and critiquing programs. He almost cried as he read through one of the programs I received. We showed demos every Tuesday until the 15th of June, since neither of us would be present in class on Fridays. 4 June 2010 was ARML and the Friday after that was afterprom. In addition to the 15th being our last day of class, I decided to have a party for celebrating the end of one year for Computer Team. After two more demo days, the contestants were confident that their programs would fare well in the tournament.

20 June 2010

High Score!

After half a year, I finally finish USACO training section 2.4. FINALLY.
This has pissed me off for the past six months. 
And no, I haven't done anything about it until now. 
Actually I did, but those efforts were futile.
Until today.
When I decided to do three problems in fifteen hours.
Hello USACO training Chapter 3!
Darn this probably reflects on my insane perseverance for random things.
Dattebayo :D

17 June 2010

Battleship Chronicles, Part I

The 2009-2010 academic year was quickly ending, so I needed a worthy activity to wrap up my club/elective/academic team thingy, Computer Team (CompTeam), with a bang. Following the steps of Dr. Nevard, who assigned my Data Structures class an interactive 5-card draw program. Each person in the class had to write an AI to play that game by communicating with a `dealer' (or host) program. Originally, Sam and I planned to do Blackjack with the students, but the activity was brainstormed at the last minute, so we scrapped it. We then looked on TopCoder for more interesting interactive programs and decided on Battleship. Sam wrote up the problem statement, replicated below:

Your task is to implement a program to play the game Battleship. Here is a sample grid:

Carrier    | length 5
Battleship | length 4
Cruiser    | length 3
Submarine  | length 3
Destroyer  | length 2

A| | | |4| | |3|3|3|  |
B| | | |4| | | | | |  |
C| | | |4| | | | | |  |
D| | | | | | | | | |  |
E| | | |2|2|2|2| | |  |
F| | | | | | | | |1|  |
G| | | | | | | | |1|  |
H| | | |5|5| | | |1|  |
I| | | | | | | | |1|  |
J| | | | | | | | |1|  |

You do not know the location of your opponent's ships. Every turn, you will output a location to fire at, and you will be told whether your shot was a hit or a miss, and if it was a hit, which of your opponent's ships you have hit. The first person to sink all of their opponent's ships wins.


There will be a round-robin tournament, where every program will play all other programs k times, for some integer k to be decided. Programs will be awarded 1 point for each victory and 0 points for each loss and will be ranked on how many points they receive. If neither program has won after each program has had 200 calls to fire, no points will be given to either program. 


If you are writing your code in Java, then your files should all be contained in one package which is not the default. If you are writing your code in another language, then compile your code to an .exe file. It is ok if your program requires other files in the same directory. 

Each program will be placed in its own folder, and no program should try to access files in another folder. Programs may create or modify files in their own folder if desired.

You should implement the following pseudocode in your main function:

while (true)
 command = readLine() // Standard input
 if(command = "name")
 else if(command = "place")
 else if(command = "fire")
 else if(command = "hits")
  n = readLine()
 else if(command = "exit")

 Initializes your program. 

 Prints the name of your program to standard output and flushes the buffer.

 Prints a string which represents the locations of your ships and flushes the buffer. Your string will consist of 5 pairs of points which describe the endpoints of each ship, in order. For example, the grid above would be represented by "F9 J9 E4 E7 A4 C4 A7 A9 H4 H5". Ships must be placed horizontal or vertical, must be completely on the grid, cannot overlap, and must have lengths consistent with the table in order. Failure to do so will result in a forfeit for that match. Extra spaces in the output string will be ignored by the parser. 

 Prints a string which represents where you would like to fire and flushes the buffer. The string will be of the form (row)(column), just like above. For example, to fire at B4, print the string "B4". An incorrectly formatted output or out of bounds output will result in a forfeit. Extra spaces in the output string will be ignored by the parser.

 n will be a number representing the index of the hit ship in the above table, or 0 if no ship was hit. For example, if n = 2, then you hit your opponent's battleship. Your program should process this data however it likes.

Other Information:

- After every call to fire, there will be a call to hits, even if your program has already won. After this, if a program has won, both programs will be told to exit. 
- Your program cannot get a hit on a square multiple times. If your program fires on a square more than once, it will always be a miss. 
- Please test your code before you send in your final version. 
The competitors seemed pretty excited about it. I also opened it to anyone remotely interested (aka people on my mailing list). For the first few classes, I let them work on their programs. As expected, they got a bit bored on the second or third class.

Notepad in WINE (Ubuntu 10.04)

When I tried to save a file in Notepad under WINE, I got the following error. I thought this was pretty hilarious.

The entire screenshot:

15 June 2010

New Mac mini

Today marks the date of the 2010 refresh of Apple's diminutive computer, the Mac mini. The computer was introduced back in January 2005, at the annual MacWorld conference, from which Apple defected four years later. The first generation of the Mac mini was also my first OS X-era Macintosh; the other Mac I have at home is a 1990 Macintosh Classic from the days of my dad's graduate studies at Princeton.

The Mac mini served as Apple's lowest-end machine, used to woo Windows users to the land of Apple. Current Mac users used the machine for home theater purposes or as an addition to their current Mac family. Either way, it was priced at a tempting $499 (Intel machines started at $599).

It was a really small and cute computer, but by no means powerful. My machine was equipped with a 1.25GHz RISC processor, 256MB of memory, and 40GB hard drive. However, it served as an excellent introduction to Mac OS X and the rest of the UNIX and digital media creation world. It was on that computer that I experimented with video editing, photo organizing, and website building.

from left to right: PowerPC, Intel rev. a, Intel rev. b (credits: iFixit)

Fast forward five and a half years. The Mac mini has evolved into a beast since the Intel transition. The current machines are at least twice as fast, if not more. They have a dual core processor, plethora of memory and disk space, and a much faster graphics subsystem. Any Intel Mac mini could whip the G4 back into its stable (when running processor-native software, that is).

Today's machine is equipped with a 2.4GHz or a 2.66GHz Core 2 Duo, 2-8 GB of RAM, 320 or 500GB disk, and a Nvidia 320M integrated graphics chipset. These specs are identical to those of the MacBook Pro 13". Unlike the MacBook Pro, the new Mac mini got a chassis revision as well -- surprise!

woah! (credits: Apple)

No one expected the spanish inquisition a smaller, thinner, unibody chassis with a removable cover! This is perhaps the biggest upgrade the Mac mini could have received. Previous, to open the chassis, one had to pry the main unit from the aluminum and plastic chassis with a putty knife. The new unit has a round, plastic cover on the bottom that not only is the base of the machine, but also doubles as the port from which the internals of the machine are accessible.
closed (Apple)

opened (Apple)

The machine now features an integrated power supply, which means that it does not require a ginormous power brick to power the machine. Additionally, Apple subtracted a USB port, but added an HDMI port for home theater purposes. An SD reader sits on the rear of the machine for easier photo downloading purposes.
new port layout (Apple)

Also of note is the lowered power consumption. The machine comes with a 85W power supply instead of a 110W unit from the previous Intel units. At idle, the machine sips a measly 10W, making it one of the least power-hogging consumer desktops available. 

Today's announcement is not all good news, however. The price of this entry-level machine hiked northward of $100! This was, too, unexpected. Why would Apple increase the price of their already expensive low-end machine even higher?! All for the upgraded internals and the stunning unibody enclosure? Who knows. 

From perusing MacRumors not long after the new machine was announced, many people rejoiced at the revision, mostly because of the stunning, unbelievably thin enclosure. Others ranted about the lacking hardware, notably the following:
  • No Blu-ray
  • Intel i3, i5, i7 processors missing
  • Thin enclosure prevents the use of cheaper, desktop-sized parts
  • High price for a machine with outdated hardware
Unsurprisingly, the $999 server version did not receive much fanfare. It includes a 2.66GHz processor, 4GB (upgradeable to 8GB) memory, and 2x500GB disks. To me, this is, hands-down, the best better value Mac mini (there are only two Mac mini models this time). I would even go as far to say that this is the best value Mac for me; it comes with an easy-to-use UNIX based server grade operating system without a tremendously bulky case or high power consumption. By stating my preferences, I am placing value on the tiny enclosure and its energy efficiency, which many people overlook. Of course, many people would rather have a large desktop machine for expandability purposes and easy servicing; that is their preferences. I do not know what everyone else wants; I only know what is best for me.

Overall, this is a great computer for anyone looking for a small, efficient, and pretty desktop machine for low to medium powered computing tasks. It should be great for playing 1080p video or some light gaming; it certainly will not handle anything intense. It is also recommended for anyone who needs a light to medium duty web server without extraordinary data storage requirements. I strongly recommend the server model over than the `consumer' model; you would get a much more powerful computer at the same price or one with the same power at a much lower the price, given that you do not mind a louder, bulkier, and more power consuming computer.

11 June 2010

Prom: Epic win++?

There are some events that every high schooler is encouraged to go to (otherwise they won't get the ``full experience,'' I suppose), and one of them is prom. I had already skipped Junior Prom for ACSL All-Stars, which truly was a blast, from playing Super Smash Bros 64 on my MacBook Pro with an Xbox 360 controller and a Wiimote, to tricking the intermediate team into thinking that Sam, Kamran, and I got only a 5/40 on the programming questions because we were too busy playing Smash and Mario Kart. Unfortunately, the computer-oriented event that semi-overlapped with this year's Prom was Apple's WWDC, which would have cost me a whopping $1600, not including travel expenses. Being a cheapskate and super-conformist, my mom forced me to go to prom. Sucks.

My mom bought a dress in New York and I picked out a pair of relatively comfortable shoes at Macy's. Supplies: check.

A few days ago, the daughter of a class parent sent out a request for songs. Of course, having nothing better to do (as Bakura would say1), I took a look at the spreadsheet and was disgusted by the overflowing barrage of twenty-first century pop songs. I then stealthily inserted the following songs:
  • Rick Astley - Never Gonna Give You up [classic]
  • Erasure - Always [Robot Unicorn Attack song]
  • Klein Four - Finite Simple Group (of Order Two)
  • Littlekuriboh - Leather pants
Note: Julia beat me to Brooklyn Rage and also put a bunch of Beatles and '80s songs.

We figured that out of the three-hundred some songs, they would pick at least one of our songs. So we were content and felt very confident that this was going to be the most epic prom ever.

Then prom day came and I left school early to get hair done and other miscellaneous businesses. I took a shower, went to get my hair done, and did my nails. How atypical and troublesome. I left for Yumi's around 5:15, thinking that we would only take half an hour to get there (because GMaps said so), but there was tons of bad traffic, so we got there in an hour. Julia had already arrived and was comfortably situated on the couch, playing Fire Emblem (GBA) on her DS. She certainly came prepared. Then Alex Lam came, and he and Yumi put on their respective flowers (corsage and boutonnière, respectively). 

We went outside and took some pictures. I was surprised by the camera's post-processing in the Auto modes. The colors were vibrant and popped. This is a terrible conclusion; I just glanced at the images on the Rebel XT's 1.8" screen for 5s. I'd have to import them to my workstation and view them on my Dell Ultrasharp screen. I then took some pictures in the manumatic modes, but those weren't as vibrant. I'll have to look into that later.

Then we went to the Rockleigh Country Club for the actual event. We arrived pretty early, checked in, and got our pictures taken (yet again!) The photographers had Canon EOS 1D Mark IIIs with 24-70L lenses. I'm not sure if they were 1D or 1Ds; I just noticed the Mark III on the lower part of the camera body.

We got some appetizers and talked to other people. Julia sampled pretty much every offering, thus nearly filling herself before dinner XD Lots of people were amazed by my hairdo (insert Kemo2 jokes here). We then went inside the ballroom to start eating and dancing. I got up and danced a little with Julia, Yumi, and Alex (more like, we held hands in a circle and rotated at a somewhat high rotational velocity). Sam and Patrick (super troller) sat at our table for most of the event.

Some things of note:
  • Patrick was surprised that I was the one to put the Rickroll and RUA song on the song request spreadsheet. Actually, a lot of people were. (cue ``Oh, that was you?!'') In Data Structures, Rushdoony was like, ``If they play Always, I--I wouldn't know what to do O_O'' Anyway, Patrick said that I would be his hero if both songs were played. We requested Always, but it seemed like the DJ didn't have that song. Sadface T_T
  • A lot of people were surprised that I brought transcripts of Brooklyn Rage, Leather Pants, and the first YGO:TAS episode in my purse. When the DJ played Bad Romance, Jordan, Julia, and I sang Leather Pants (parody of Bad Romance). That was awesome :D
  • Quite a few piano geeks (Dan Abolafia, Beata Safari, Andy Wang, Andrew Kahn, and Sam Fingeret) played the piano in the main hall. The Rockleigh Staff didn't notice until 23:00, when he told the group to stop playing because they needed the piano in tune for the next day, when an invited guest would perform. Oblivious fail?
  • Alex, Yumi, Julia, and I must have seemed really stupefied while we recited the YGO:TAS Episode 1 script. Alex Lam has a really squeaky voice o.o Also, Julia and I fail at singing Brooklyn Rage a cappella. XD
  • Prom got really boring at 22:00, when the DJ played lots of songs I didn't know. I just sat at my table and watched Julia, who sat next to me, play Fire Emblem. Aside: I did get to play one game of Sudoku right before dinner! By 23:00, we all sat outside, occasionally asked for the time, and watched various people play piano without getting caught XD
  • THE MUSIC WAS SO LOUD. My temporary hearing loss was amplified when I stepped outside of the ballroom.
It turns out that none of our troll songs were played (but lots of trite, pop songs were). Disappointed, we left prom with a face of disapproval.

I don't know what it would be like to not have gone; I know that I would be sitting at home working on Battleship (which still needs massive improvements by my standards). I guess I would have been more bored if I had stayed at home. Prom would have been better if I went with someone (*cough* Brian Hamrick), but I am grateful for the time I had.

Hey, at least I trolled the song request spreadsheet :)

Verdict: I paid $50 ($55 prom ticket - $5 lunch; price of uber fancy senior luncheon) to destroy my already-busted hearing.

1: Bakura has nothing better to do when he was about to be dragged into Marik's quest to obtain Yami's Leather Pants.
2: Kemo always announces ``Attention Duelists! My hair ...'' when he wants to say something. Example: In episode 13, Kemo said ``Attention Duelists! My hair is definitely not leading you into a trap!'' when he lead Kaiba to Mokuba's jail cell.

05 June 2010

ARML 2010

AN: Because it's getting a bit late and my conscience is telling me to write Battleship, I'll try to make it decently to the point.

Friday was the start to everything. I left two hours later than the school since parents were driving me, but arrived at Penn State only twenty minutes later. I lent my PS/2 to USB converter to Alex Kim so he could use his keyboard to play starcraft, touched base with Dr. Mayers and Dr. Abramson, and then hung out with Jenny Yung for most of the day. We went to the creamery, walked randomly for about a mile, and then ate my quiche after my team meeting. Then I met some of the TJ friends. They're definitely not as nerdy as Pavel or Ian, not as antisocial as Sam, and not as random, brash, or unpredictable as me. I stayed till 22:00 for the song contest. Mark's troupe made a phenomenal showing, but Lehigh out-cheered us with their army of high-pitched girly screams situated in the front row. In any case, everyone who saw our performance should know that the Catalan numbers have the form `one over n plus one two n choose n' and are used for `trees, walks, and cut-up blocks.' Yep, those are partial lyrics from our song, a parody of `I'll make a man out of you' from Mulan. :D Unfortunately two other teams decided to do that, but they failed.  That concludes day one.

Saturday was the day of the competition. The problems were harder this year and mostly everyone did worse than usual. They had nice tricks to them, but I failed to arithmeticize properly. Three people, John Chiarelli, Jongwhan Park, and Michael Tan, received high honors for scoring 7/10. We (AAST A1 or informally Mu A) got ninth, our second best finish in the team's history. Yay :D (We also were first to hand in an answer for the super relay, but failed because Ian, the middleman, explozored. Ah well. :( no candy for us XD) At the end of the day, while everyone was walking to the buses, I spotted Jenny from behind and tackled her :D Yay momentum conversation conservation! Then I went home with parents.

In any case, this was a spectacular finish for Math Team 2009-2010.