Format of the tasks

Regular input/output tasks

The tasks should follow these rules in order to be usable by the system:

• A task consists of description, input files and output files.
• All the files should be in 1 folder without any subfolders.
• The description of the problem should be in pdf format and should be called description.pdf.
• The input files should be in the format {name}.in{number}. For example: rods.in01, highways.in10.
• The output files should be in the format {name}.ans{number} or {name}.sol{number}. For example: rods.ans01, highways.sol10.

The system will match the input and output files by sorting them and making a 1:1 matching of the two sorted sequences. This means that if the number suffix of the input and output files match everything will be ok. For example if you have the following files:

rods.in00, rods.in01, rods.in02, rods.ans00, rods.ans01, rods.ans02

The system with sort the “in” files and the “ans” files and will match the files at the same position, which means that the matching will be:

rods.in00 → rods.ans00
rods.in01 → rods.ans01
rods.in02 → rods.ans02

The general rule of thumb is that if your “in” and “ans” files are numbered properly you are good to go!

Tasks with checkers

The only difference of the tasks with checkers is that a checker executable is needed. This file should contain the word checker in its name and should be executable by a 64bit x86_64 linux system. It could also by written in a script language like perl, bash, ruby or python.

The checker should return exit code 0 if the solution is correct and non-zero in any other case.

Examples for checker names: checker, checker.py, my_checker.sh

The checker will be executed with the following parameters:

{checker} {input_file} {answer_file} {contenstant_output}

As you see the “ans” file will be passed to your checker, so you can store some useful things for the test that you could need. The checker will also receive the input file of the test.