If no-one objects, I will organize the next Golf tournament somewhere around Easter next year. I won't call it the Easter Apocalypse, however, as that will not be appreciated by some people...
> While it is still fresh in everyone's minds, I thought I should > make some notes on possible improvements for the next apocalypse. The word 'apocalypse' is already in use for a type of Perl Golf tournament, so it is perhaps not the right name. I'm open to suggestions. > 1. Timing > > We probably all spent more time on this than we can afford. > I think 5 days was too long; 2-3 days feels about right. I think 5 days is just the right length. After all, quality code costs time, and all of the runners-up achieved their 91 score in the last two days. Beginning on a Thursday seems to be a good idea. > It seems fairest to announce the game start time two weeks (say) > before the event, to give people time to prepare. Yes. > 2. Tie-breaking rule > > I chose to break ties by rewarding the first to post. > I suppose other ways are possible (e.g. reward the more > efficient one) but they all seem a little artificial. I like the idea of awarding prizes to the 'best' or 'most original' solutions. Perhaps the 'first to post' rule is best for the overall standings, while the 'best per hole' prize will go to the most original entry. > 3. Number of Holes > > Though 9/18 is traditional in golf, five seemed sufficient to > provide an interesting spread of scores. Any more than five > may be unnecessarily cruel. > > 4. Hole Difficulty > > When I posted the game, I thought the holes were too easy. > In retrospect, I think they were about right because they were > simple enough to allow novice golfers to have a go, while still > providing a challenge for the elite golfer. The difficulty of the holes is not easy to judge. Probably I will go for three or four easy, short holes, par 30 or lower, and one or two longer ones, with par around 80, say. > 5. Individual Hole Scores - to post or not to post? > > The individual hole scores were kept secret until Eugene, in a > sportsmanlike gesture, revealed his leading scores about 16 > hours from the end. I think this worked quite well. > > However, I suggest that in future games the Arbiter should reveal > the leading scores for each hole about 4-8 hours from the end. > This should make the final hours quite exciting. It should be somewhere between 12 and 24 hours to give everyone in all time-zones the chance to read them. > 6. Perl Version > > Interestingly, I never stated the Perl version, and had no > trouble in this area! I suppose it should work on the > latest stable version of Perl. All solutions should work in perl 5.6.1, will probably be the rule next time. > 7. Scoring Rule > > There seem to be two reasonable scoring rules: > 1) The "cross-platform" one-liner that I chose. > 2) The multi-line rule (with newline counting as 1, > but not on the leading #!perl line) as implemented > in Keith C Ivey's submitted GolfScore() function. I think next time multi-line programs will be allowed, with newlines counting as one stroke. > ... Had I allowed multiple lines, I am > certain Eugene would have found the multi-line solutions > found by others on hole 4. I'm not so sure about that. I didn't consider using multiple lines at all. > 8. Fairness > > I think the key to a fair game is a really tight test program > on day one (tsanta.pl had too many holes). It is ideal if you > can just say "if it passes the test program, it is ok"; > that also eliminates ambiguity about the game's semantics > and spares you from having to describe the semantics. I don't think that can be done. Some rules should have been a bit clearer, but you can't foresee every loophole that will be used. I found the test program very useful, so as a referee I will make it public at the start of the competition. However, programs that pass the test program but have fatal effects (output to STDERR, fail for n>100 etc.) will be disqualified. Eugene
