|
Match Editorial |
 |
|
||||||||||||
| |||||||||||||
| MATCH EDITORIAL LINKS: | |||||||||||||
|
|||||||||||||
| |||||||||||||
April 10, 2002
Match summary
The 300 was extremely simple, requiring nothing more than "implement what we just told you to." Some people chose to make functions to determine if squares were Latin or orthogonal (see NDBronson's solution for an example) whereas some people just hacked it into a single function (like ZorbaTHut). In the end, it's a simple matter of accumulating all the data together and making a big if statement.
The 500 was a little more complex, but in the end it's just a brute-force system. Check each possible move and see how many stones you'd get in your home pit, then return the best one. The only tricky part is that if the last stone was placed in your home pit you have to check all the next possible moves again, but the numbers are small enough that there's no danger of timing out. Aside from that it's just a matter of getting the logic right.
The 950 was difficult in theory, but the low constraints made it much easier than it would have been otherwise. It's quite possible to go through and just test every single possibility in some matter. My personal favorite solution is dmwright's. He keeps an array of the four values and for each step he "accumulates" two of them together with some operator, recursively so he gets all the possible values. Then it's just a matter of keeping track of the current "best". A common mistake was to only do the operators in order, which wouldn't allow results like (3/14)+(11/14). In fact, this is the mistake that I made :P
