Email Solving Problems Thu Sep 28 19:10:01 EDT 2006 Help This help file is for contestants who are using their own personal computer account to solve problems and are submitting those problems by email, and who are also NOT using the email UNIX tools described in the email_unix_ tools help file. Contestants using an account given them by those who run the contest, or who are using the email UNIX tools, should read the `solving' help file instead. Contestants using the email UNIX tools should read the `solving' and `email_unix_tools' help files. Communicating with the Autojudge ------------- ---- --- --------- You communicate with the autojudge by email. The auto- judge has an email address which should be on the contest web page, or which you were otherwise given. All messages should be PLAIN TEXT and NOT HTML. If a file is to be put into a message, it should be INSERTED into the body and NOT ATTACHED. Unless instructed otherwise, the file should be the ONLY thing in the message body. If a file is not to be included in the message, the message body should be COMPLETELY EMPTY. A file included in a message should NOT have a line con- taining the character string `File: FFFF' in its first block of non-blank lines, where FFFF is character string ended by whitespace or a line end, unless FFFF is the SAME as the file name in the `Subject:' field of the message. Help Files ---------- The help and demonstration files should be on the web, e.g., should be linked from a web page for the contest. If not, you can get them by sending TWO emails to the autojudge with an EMPTY BODY and the subjects Subject: get help Subject: get demos The return email will have multiple files per message, with the files separated in an obvious way. What Problems? -------------- The problem descriptions may be on the web, but if you are in a timed contest, the problem descriptions will NOT (usually) be on the web, and you will have to get the problem descriptions by sending email. When you do this you will start the clock that times how long it takes you to solve a problem. If you are getting your problem descriptions from the web, you can skip this section. To get a problem named pppp you send email to the con- test autojudge with an EMPTY BODY and Subject: get problems/pppp You will get back a problem description file and a Makefile. The Makefile may not be of any serious use to you if you do not have UNIX for your personal account, but it does contain information on time and memory limits that the judge uses when testing a submission. There should be an index of all the contest problems on the web, but if not, send an email to the autojudge with EMPTY BODY and Subject: get help/problems to get the index. Asking Questions: ---------------- You may think that a problem description is ambiguous, and ask the judges for clarification, though you should be careful to think the situation through thoroughly first. To ask such a question, just send ordinary mail to the autojudge, taking care that it's subject does not begin with `submit' or `get'. A human judge will be notified and eventually respond. If you ask for a clarification by e-mail, and a signifi- cant answer is given, that answer may be given by post- ing it on the scoreboard so everyone can see it. You may not receive email back in this case. Working on a Problem -------------------- For a problem named `pppp' you should create a directory in which to work on the problem and write a file named `pppp.c', `pppp.cc', `pppp.java', or `pppp.lsp' in that directory. The suffix of the file you write determines the programming language you are using: .c for C .cc for C++ .java for JAVA .lsp for COMMONLISP Your program should be written to take input from the terminal and put output to the terminal. In C this means using functions such as `gets', `scanf', and `printf' that implicitly use `stdin' for input and `stdout' for output. In C++ this means using `cin' and `cout'. In JAVA this means using `System.in' and `System.out'. In COMMONLISP this means using `*standard-input*' and `*standard-output*'. You should NOT, repeat NOT, write output to the standard error output, `stderr', `cerr', `System.err', or `*standard-error*'. Such output will result in a `Program Crashed' score. You should NOT under any circumstances open a file in your code. In the judge's program execution environ- ment, output operations on opened files fail, in order to protect the judge's software from wayward submis- sions. Since you will likely not be checking for output failures in your code, your code will mysteriously pro- duce no output in the judge's environment if you open an output file, and will be scored `Program Crashed'. When the autojudge executes your program, it will be called with NO program arguments. You can use this fact to write out debugging information to the standard out- put IF your program is called with one or more program arguments. To submit your program code, you send a message to the autojudge with a subject of the form Subject: submit pppp.c and plain text body containing nothing but a copy of the file `pppp.c', if you solved the program in the C pro- gramming language. If you chose a different language, replace the file name by the appropriate one chosen from `pppp.cc', `pppp.java', or `pppp.lsp'. Send this message as PLAIN TEXT, and NOT HTML. INSERT the file into the body, and DO NOT ATTACH the file. The file must be the ONLY thing in the message body. You can test all this with the file demos/count/count1.c by sending a message with Subject: submit count.c and with the file inserted in the body of the message. Note the `Subject' has `count.c' and NOT `count1.c'. Submission Alternatives ---------- ------------ In some contests, particularly those with `feedback' scoring, there are alternative ways of submitting a problem that require a `qualifier' to be added to the end of the subject. The possible qualifiers are: in Returns score, and when practical, returns the judge's input for the first failed test case. inout Ditto but returns both judge's input and judge's output for the first failed test case. solution Returns score, and if the score is `Completely Correct', also returns the judge's solution to the problem. Thus if your solution is `pppp.c', and your qualifier is `inout', your subject is Subject: submit pppp.c inout The scoreboard in a `feedback scored' contest is not based on time, but is instead based on the submission qualifiers you used when your solution was still incor- rect. A submission without qualifiers, that gets no feedback from the judge's test cases, has the least penalty. The `in' qualifier has the second least penal- ty; and the `inout' qualifier has the greatest penalty. There is no penalty for a correct submission, and the `solution' qualifier behaves like a missing qualifier for an incorrect submission. If you have already submitted a correct solution, you can resubmit with a `solution' qualifier to get the judge's solution, without any affect on your score. Timed contests and some other contests disallow most submission qualifiers, in which case the submissions with disallowed qualifiers behave as if they had no qualifier (except they also return a note saying the qualifier was disallowed). Resource Limits -------- ------ In addition to a description, there should be a `Makefile' for each problem. This contains memory and time resource limits which constrain the problem. Memory limits are typically several megabytes and time limits are typically 10 to 60 seconds. Harder problems require care to be sure you stay within these limits. Most problems are such that solutions in C or C++ will run in a few seconds. If you have long running times, you may have chosen an algorithm too inefficient to avoid the time limit. Debugging --------- The best way to debug is to include code that prints extra debugging information to the standard output if your program is passed any arguments. For C, such code might look like: int debug; #define dprintf if ( debug ) printf int main ( int argc ) { debug = ( argc > 1 ); // # arguments = argc-1. . . . dprintf ( ... ); } See the C++, java, and commonlisp help files for debug- ging in other languages. Judge's invocations of your program will not have ANY program arguments. For program crashes and infinite loops, it is quickest to use a debugger, if you have minimal familiarity with one of the available debuggers. A typical usage is gdb pppp run < pppp.in ... program crashes, or control-C is pressed ... ... to get out of an infinite loop ... back [this lists frames] frame # [# is number of correct frame] list [lists code near crash] p EXP [print value of expression EXP] Other Issues ----- ------ The following help files may be useful for: Understanding problem scores: scores Understanding the scoreboard: scoreboard File: email_solving Author: Bob Walton Date: See top of file. The authors have placed this file in the public domain; they make no warranty and accept no liability for this file. RCS Info (may not be true date or author): $Author: walton $ $Date: 2006/09/28 23:14:22 $ $RCSfile: email_solving,v $ $Revision: 1.5 $