Here is a collection of answers to questions, clarifications and other bits of late-breaking information we are assembling as the contest develops. ------------------------------------------------------------------------------- Question: 2) the first condition is that my move has to change the configuration of the board or I loose. But does my move has to change the previous (one turn) configuration, or it's for all the configuration for the entire game (ie: do I loose if my configuration is the same that for the 2nd turn, or for the 23th turn, or just the previous turn) Answer: This question has come up repeatedly. You can't repeat *any* previous board state that occurred in the history of the game. That's why a complete board state has to include a description of the moves that led to the particular configuration -- history counts -- as does the whose-move-is-it bit (see the following question&answer). This rule keeps the player from being able to loop in board-state space -- so the game tree is guaranteed finite. ------------------------------------------------------------------------------- Question: When deciding whether a configuration has been repeated, is the side-to-move part of the configuration. That is, suppose that a particular configuration has been reached when it is X's move and then the same configuration is reached when it is Y's move. Does X lose because now the configuration is repeated, or is the fact that it is a different player's move make it a different configuration? Answer: Another good question that has come up repeatedly. Suppose you and I are playing pousse. If it's *your* move and you put the board into state S that has occurred previously, it's OK as long as *you've* never put the board into that state. If *I* was the player that caused the previous transition to S, you don't lose. If, on the other hand, *you* have previously caused the board to go into state S, then you have looped, and it's "game over" -- you lose. In other words, the state description includes a bit stating whose turn it is to move. ------------------------------------------------------------------------------- Question: Since the task is to read in a partial game and output the best move, this doesn't make sense: The program is run once for every move and then terminates; the current move state will be passed to the program on standard input. Persistent inter-move state may be kept in the "support/" directory if desired. A possible interpretation that the program will be run on several games, and might want to save intergame state exists, but that conflicts with the statement that the "current move state will be passed to the program on standard input". Answer: It makes sense. Here's how it works: we are going to play a tournament among the entries. Let's say that during one match, you are playing against Simon Peyton-Jones' Massively Parallel Awk/TCL entry. As the match progresses, every time we need you to make a move, we run your program. We feed it, though stdin, the described format that gives it the current board state and the history of the game up to that point. Your program then thinks real hard, chooses a move, prints it out, and expires. We look at the move you made. If it's illegal (say, you said B19 on a 17x17 board), you lose. If it's a losing move, you lose. If it's a winning move, you win. Otherwise, it's Simon's turn -- we run *his* program, and feed it the *new* board state/history. And so forth, back and forth between your program and Simon's, until the game is decided. Now, when your program is executed, by the time it has chosen its move, it may have a lot of computed state that it could profitably use the next time we run it -- when it needs to make the *next* move. So your program might want to write out some of this expensive-to-compute data to a file, and slurp it back in when it is next executed. Or not. It's up to you... But you better consider all the angles, because Simon's a mean Awk hacker, and he won't miss a trick. ------------------------------------------------------------------------------- Question: 1) if I have (for a line or a column): | |X|O|X| and I play R, the entire line move to the left. But if I play L, does the entire line is moved or as there is a room for my play the line doesn t move (ie: |X|X|O|X| or |X| |X|O| ??) Answer: The rules are clear on this. If you push an X marker in from the left on the row | |X|O|X| then you have |X|X|O|X| ------------------------------------------------------------------------------- A note on submissions: If you are shooting for the Judge's Prize, and your entry doesn't fit into the strictly-defined submission guidelines -- don't worry about it. In order to be eligible to play in the tournament, you have to fit in with the described interface and directory structure. But if you have a fancy 3D interface, or some other interesting super-cool but non-standard system, and want to be considered for the Judge's Prize, then just do what you think is The Right Thing. Just make sure you describe things clearly in a "readme" file, and inform us that you aren't going to play in the general tournament. (We may play your system against the other entries anyway -- but no promises.) ------------------------------------------------------------------------------- Cheating ethically: We have defined a new pro-cheating policy that we hope will give some of the more piratical teams a chance to have fun in a guilt-free way. Let us suppose that you think you can outsmart the judges, and write a program that will win by somehow arranging to steal extra time on the computer, or by subverting the win/lose metric function, or by sending packets back to your officemate, who is a 7th-dan professional pousse player. We have a mechanism for recognising your cleverness, without penalizing honest players, and without you having to do anything sleazy. Here's how it works: You write your program and submit it. You do not inform us that your program is shady. We run the tournament, and choose 1st and 2nd place winners. *After* the tournament, we will announce a one-week window, before we've announced the tournament winners, where you must contact us and disclose your clever tricks. Your program is not eligible for the actual 1st and 2nd place awards, but you are still in the running for the Judge's Prize. If you have pulled a clever hack -- clever enough to *really* impress us -- then your program is definitely a solid candidate for the Judge's Prize, and we'll be delighted to describe your cleverness at the award presentation and in the post-contest writeup and prize citations. Failing to let the judges in on things is, of course, unethical, sleazy cheating. No more to be said about that. If you disclose, but we'd already caught your program anyway -- nice try, no cigar. Heavy-handed techniques, such as trying to fill up the disk or erase someone else's directory, will not impress the judges. Not that we are naming names, but there's a full professor at a top university -- someone with a major reputation in functional programming language circles -- who achieved some early notoriety as a young grad student in precisely this manner. ------------------------------------------------------------------------------- Question: is it ok to seek on a ICFP'98 contest submission's standard output, and propose a new move instead? Or do we have only one try (which means we must deal with signal handling, in a conservative way)? And is it ok to output spaces or after the coordinates of the move (so as to overwrite a longer move intent)? Answer: Don't try to seek on stdout. No spaces allowed in the output, although we'll allow an optional newline after the move. If a program is still *alive* after 30 sec, it loses. So the programmer has to watch the clock and bail out when the program edges up on 30 sec. So the technique of printing better and better moves on stdout as you discover them until you run out of time is not useful anyway -- it's easy enough to store the best-move-so-far inside the program, and when time's up, print it out. ------------------------------------------------------------------------------- Question: The strategy seems fairly different when N is big. May we have a better idea of what N (or Ns) will be tried during the tournament? Answer: We could tell you. But then we'd have to kill you. ------------------------------------------------------------------------------- Question: Will gcc + common include files + common libs be installed on the tournament machine? Answer: We've slightly liberalised our "naked machine" kernel-only policy. Marc's summary: "Gcc will be available. As for libs, I'm not going to enumerate each and everyone that is available. I only guarantee that "vanilla" programs will compile (to be safe)." ------------------------------------------------------------------------------- Question: Is it OK to mix languages? (C/ocaml in particular) Answer: Yes. ------------------------------------------------------------------------------- Question: What is your I/O configuration? Disk speed, bus speed, etc. Might be important :). Answer: All I can say is that a single 2GB IDE disk is connected. ------------------------------------------------------------------------------- Question: I'm allowed to have more than one entry in the ICFP'98 Functional Programming Contest? (e.g. a standard-known-to-work, a cheating and a experimental-specialized-for-N=18 entry) Answer: The more the merrier! Just submit each one to a different directory. ------------------------------------------------------------------------------- New policy: So many people have been pounding on us about the difficulty of building support software on the Marc's tournament box, we have caved in and are liberalising the install policy: For *ALL* entries we will do cd make once before the tournament starts. If there is no makefile then nothing will be made (as per old rules). So you may now place a makefile in your top-level directory: ./runme ./readme ./Makefile ./support/... ./src/... Marc has the standard gcc installed by Red Hat install. If you have any doubts at all about the libs you need, include what you need in your support/ directory and link against those. -------------------------------------------------------------------------------