]> mj.ucw.cz Git - eval.git/blob - doc/tasks.html
Added TODO items after brain-storming with Gavento.
[eval.git] / doc / tasks.html
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html40/strict.dtd">
2
3 <html><head>
4 <title>MO Eval - Tasks</title>
5 <link rev=made href="mailto:mj@ucw.cz">
6 <link rel=stylesheet title=Default href="mo-eval.css" type="text/css" media=all>
7 </head><body>
8
9 <h1>Tasks and their types</h1>
10
11 <p>MO-Eval supports the following standard types of tasks (new task types can be defined, but
12 it takes some effort):
13
14 <ul>
15 <li><b>off-line tasks</b> &ndash; program reads input (from a file or from stdin) and then produces
16 an output (to a file or to stdout). Then a <em>checker</em> (a.k.a. judge) program is run, which decides whether the output
17 is correct. If there is only one correct output, the checker can be just a call to <code>diff</code>.
18 In case of tasks with complicated scoring, the judge can also assign points explicitly. See comments
19 in the top-level config file for the exact interface of the judge.
20 <li><b>interactive tasks</b> &ndash; program needs to react interactively, usually by reading from stdin
21 and sending results to stdout (sometimes the communication protocol is abstracted out as a library
22 which the tested programs are linked with). In this case, the judge's stdio is cross-connected with the stdio
23 of the tested program.
24 <li><b>open-data tasks</b> &ndash; the contestants don't submit a program, but a set of output files instead.
25 Judged similarly to the off-line tasks.
26 </ul>
27
28 <h2>Setting up a task</h2>
29
30 <p>To define a task, you should create a directory <code>problems/</code><i>task_name</i> and populate it
31 with the following files:
32
33 <ul>
34 <li><code>config</code> &ndash; local configuration file for the task, which overrides defaults
35 set in the top-level config. Task type, list of test cases and many other things can be defined
36 here. Consult comments in the top-level config for explanation.
37 <li><i>test</i><code>.config</code> &ndash; each test case can have its own local overrides
38 of configuration, used for example if you want to have some test cases with a different time limit.
39 <li><i>test</i><code>.in</code> &ndash; input data for the particular test
40 <li><i>test</i><code>.out</code> &ndash; correct output for the particular test (optional)
41 </ul>
42
43 </body></html>