On 11 Dec 2001, at 21:54, Eugene van der Pijll wrote: > > 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.\
What type of tournament is that [for us golf non-cognoscenti]? > > 2. Tie-breaking rule [...] > 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. How about "the shortest solution that no one else got" [modulo the obvious homeomorphisms, of course] for being a somewhat idiosyncratic award? > > 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. I think this is a VERY subtle semantic problem.. I've been pondering it some and can't find a good/equitable solution. My instinct is to prefer a clear "text" wording of the requirements of a problem, but then you have the inherent vagaries of language to contend with. But if you make "the scoring program" but the sole/primary criterion, you run into oddities, and programs that can take advantage of clearly unintended aspects of the _particular_ data sets and constraints used in the scoring program. In particular, how do you define 'fatal effects'? What if a program fails on EBCDIC input, but it passes the scoring program? I think you could argue that if you want 'writing to STDOUT to be a fatal error' then the scoring program ought to catch it, and if it doesn't, then it should be presumed legal if you're going to have the scoring-program-behavior be the discriminant. no? Even for file-lengths: you say failing on files >100 lines would be fatal. Would failing on files with >2^64 chars be fatal? Would faililng on files with a non-US locale? [or a non-ISO-Latin charset?] It seems like a real can of worms. I confess that all that together, I am still inclined to have the "official" description be the text one. And have it be the discretion of the judges whether a program violates the rules --- in this model of the world, the actual 'scoring program' would be *advisory*. Also, I'm not a golfer, but I have done these *sorts* of things in other settings and it is not at all unusual to have 'clarifications' to the rules appear as the event progresses [and of course, those 'clarifications' become part of the rules the next time, so that after you've done it a few times you have things pretty well nailed down]. It would mean more up-front work, but it would only have to be done once [and could be done collectively by us all]: primarily to make a general set of rules. The general set could include things like "The program may not write any data to any file descriptor except as explicitly specified in the particular problem". "When a problem mentions a 'file', it will be a normal, sequential-access-but-seekable file using standard ISO-Latin-8 with a US- English Locale; the file may be of any length but its length will never be larger that 2^16 bytes", etc.... And I think that with a good set of 'general rules' you'd be able to do very clear, intuitive and solid problem-descriptions in ordinary English. And then I think you should *not*reveal* the scoring program. The program's behavior should be against the *description* of the problem it is to solve, _not_ against a [perhaps] programming error in the scoring program. If there's a question, it should be addressed to the judge [NOT to the scoring program source code] and the judge can make public an appropriate 'ruling' [that is, 'clarification' of either the rules or the particular problem]. /Bernie\ -- Bernie Cosell Fantasy Farm Fibers mailto:[EMAIL PROTECTED] Pearisburg, VA --> Too many people, too few sheep <--
