Information for Problem Providers

This page contains information for persons and organizations who want to provide problems for the challenge.


The .tar, tar.gz or .zip packages submitted by the problem providers should contain the following elements:

  • description.pdf: a problem description, see below
  • (optional) encoding.asp: naive/default encoding that solves the problem and can be modified or replaced by each participant
  • simpleInstances/: a folder containing 5 toy instances
  • competitionInstances/: a folder containing 5 hard/competition instances
  • checker.sh: a script that checks correctness of solutions (if possible), see below

(Additional files and directories can be included, in particular additional tools for implementing the checker.sh.)


For the sake of uniform problem descriptions, we kindly ask you to structure description.pdf as follows (where the sections may contain subsections):

  1. Problem Description: The general description of the problem should contain a textual/informal description and, if applicable, a formalization thereof. It is encouraged to add examples already in this part to illustrate the ideas.
  2. Input Description: This section should describe how an instance of the problem is encoded and which predicates are used.
  3. Output description: This section should describe what atoms are supposed to occur in the answer sets and how a solution is to be extracted.
  4. Example(s): While authors are encouraged to include examples already in the other sections, at least one complete example should be given in this section that is ready to be used as a testcase for implementations. In particular, an instance (encoded as facts) and the expected answer sets should be stated explicitly.
  5. Scoring schema (only for optimization problems): A description how to compute a score for a given (correct but not necessarily optimal) solution.


For the checker.sh we use the following convention:

  • input parameter $1: path to a file containing exactly one answer set (in the format from Information for Participants) to check
  • input parameter $2: path to an instance file
  • the exit code is expected to be 0 if $1 is represents a valid solution to instance $2, and 1 if it is invalid
  • (optional) for optimization problems the standard output should be a list of pairs of form priority,cost (one per line) to specify the costs of the solution, where priority and costs are integer values and a higher priority is more important
  • IMPORTANT: If relative pathes are used within checker.sh (e.g. to refer to other scripts or tools that are part of the checker), they must be prefixed with `dirname $0`. Using just "." or $DIRNAME does not work!

(The checker.sh can but does not need to be implemented using the provided naive encoding.)