Eugene van der Pijll wrote: > > 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
besides that solutions are great, funny, clever, beautifull, they are mostly useless in real work! I'm soure that noone optimizes his(her?) tail.pl for few days to do the work which is supposed to do, isn't it? so I think that the rule should be only `if test program says ok, then it is ok'... possibly holes could be announced during the contest but the test program should stay the same 'till the end. If someone finds a way to use hole, so let it be -- it is just fun, noone depends tragically on all this I'm sure. the point is that if the program dies after output correct information it is ok, but if it prints with die (for example) it won't be catched by the test program so it is fail. if the program possibly can output the first 10 lines but cannot do for the first 100, so the test should be aware of this... (well something like this) P! Vladi. -- Vladi Belperchinov-Shabanski <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Personal home page at http://www.biscom.net/~cade DataMax Ltd. http://www.datamax.bg Too many hopes and dreams won't see the light...
smime.p7s
Description: S/MIME Cryptographic Signature
