http://blogs.mathworks.com/contest/2007/05/10/darkness-ends-and-twilight-begins/ The MATLAB Programming Contest is a semi-annual competition where contestants submit MATLAB code to try to solve a challenge. For more information, see http://www.mathworks.com/contest/overview.html Sat, 21 Jan 2012 14:45:27 +0000 hourly 1 http://wordpress.org/?v=3.2.1 http://blogs.mathworks.com/contest/2007/05/10/darkness-ends-and-twilight-begins/#comment-2112 Nick Howe Thu, 17 May 2007 00:54:19 +0000 http://blogs.mathworks.com/contest/?p=64#comment-2112 Just for the record, here are my comments on the winning Darkness entry. I actually didn't expect it to come out on top -- unlike previous contests, I didn't feel like I had any special tricks up my sleeve. The entry that won was one of a series of implementations of a simple beam search algorithm. (The first entry in the series was named BMW as a nod to the algorithm used, and successive refinements got named using a sports car theme.) The first version used a fixed beam size and was fairly slow. By the time I got to the winning entry, I was adjusting the beam size according to the size of the puzzle and the number of relatively good solutions, and I had improved the speed of the code to allow searching many more possible moves. Because the beam size directly controlled the running time of the code, it was easy to select any time/performance tradeoff that I desired. I tried to limit the number of different variants to a reasonable number, so it was partially luck that one of the entries turned out to be fairly well tuned for the test set. Just for the record, here are my comments on the winning Darkness entry. I actually didn’t expect it to come out on top — unlike previous contests, I didn’t feel like I had any special tricks up my sleeve. The entry that won was one of a series of implementations of a simple beam search algorithm. (The first entry in the series was named BMW as a nod to the algorithm used, and successive refinements got named using a sports car theme.) The first version used a fixed beam size and was fairly slow. By the time I got to the winning entry, I was adjusting the beam size according to the size of the puzzle and the number of relatively good solutions, and I had improved the speed of the code to allow searching many more possible moves. Because the beam size directly controlled the running time of the code, it was easy to select any time/performance tradeoff that I desired. I tried to limit the number of different variants to a reasonable number, so it was partially luck that one of the entries turned out to be fairly well tuned for the test set.

]]>