|
Size: 3496
Comment:
|
Size: 6187
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Problems specifications package format = | = Problem specifications package format = === Remark === For packages to be submitted via Easychair system: in case the size of the submitted package exceeds the allowed size limits, please just put an URL pointing to it. |
| Line 5: | Line 8: |
| A problem specification has to be packaged in a single compressed archive named ''benchmark_name-contributor_name.zip'' (rar/tar.gz) containing: | Submitted problem specifications have to be packaged in a single compressed archive named {{{benchmark_name-contributor_name.zip}}} (or {{{tar.gz}}}) containing: |
| Line 15: | Line 18: |
| {{{benchmark_name}}} and {{{contributor_name}}} should be substituted with their actual value. | {{{benchmark_name}}} and {{{contributor_name}}} should be substituted with their actual value. The provision of a checker at this stage is optional. A template package for benchmark submissions is available [[http://www.mat.unical.it/aspcomp2011/files/myproblem-aspteam-submission.zip|here]]. |
| Line 24: | Line 30: |
| 4. a folder named {{{instances}}} containing at least 50 numbered instances (one per file) named {{{XX-benchmark_name-MAXINT-MAXLEVEL.asp}}} where: XX is the instance number, MAXINT is the maximum integer (0 if not relevant), and the maximum function nesting level is MAXLEVEL (0 if not relevant), see Section [[#MAXINT-MAXLEVEL|Programs with Function symbols and integers]]; 5. a folder named {{{generator}}} containing the sources of an instance generator together with a README.txt file containing suitable instruction for (building and) running it; and, |
4. a folder named {{{instances}}} containing at least 50 numbered instances (one per file) named {{{XX-benchmark_name-MAXINT-MAXLEVEL.asp}}} where: XX is the instance number, MAXINT is the maximum integer (0 if not relevant), and the maximum function nesting level is MAXLEVEL (0 if not relevant), see Section [[BenchmarkSubmission#MAXINT-MAXLEVEL|Programs with Function symbols and integers]]; 5. In alternative to the point above, a folder named {{{generator}}} containing the sources of an instance generator together with a README.txt file containing suitable instruction for (building and) running it; such generator should be able to produce a number of instances according to naming given in point 4, above. Finally, |
| Line 28: | Line 34: |
| A template package for final benchmark submission is available [[http://www.mat.unical.it/aspcomp2011/files/myproblem-aspteam-finalized.zip|here]]. | |
| Line 31: | Line 38: |
| The checker reads from standard input the output of a system/call script (see [[http://www.mat.unical.it/aspcomp2011/files/LanguageSpecifications.pdf|File and Language Format]] for details) and writes in standard output a single row of text containing the string "OK", and the string "FAIL" otherwise. The string "OK" must be followed by an integer representing the witness cost in case of optimization problems. An exit code different from zero indicates a checker problem. The source code of the correctness checker has to be be included in the package; moreover, the provided software must be able to (build and) run on the Debian i686 GNU/Linux(kernel ver. 2.6.26) operating system. A checker can be a logic specification for a solver of choice: in such a case binaries of the solver must be provided together with the checker encoding. |
The checker reads from standard input a witness in the prescribed format (see [[http://www.mat.unical.it/aspcomp2011/files/LanguageSpecifications.pdf|File and Language Format]] for details) and writes in standard output a single row of text containing the string {{{OK}}} (if the witness is correctly assessed as a solution), and the string {{{FAIL}}} otherwise. The string {{{OK}}} must be followed by a space-separated integer representing the witness cost in case of optimization problems. The checker outputs {{{WARN}}} and an exit code different from zero in all other cases (e.g. the witness is not syntactically correct, or the output {{{NO ANSWER SET FOUND}}} has been incorrectly piped towards the checker). Informative messages can be output in standard error. |
| Line 35: | Line 42: |
| === Instance Input Format and Solution Output format === | Note that witnesses are assumed to be inclusive of both instance facts (input predicates) and solution facts (output predicates). |
| Line 37: | Line 44: |
| The formats for specifying both input/output of problems and instances are reported in [[#input-output|Problem I/O and Instance Specification]]). A template package for benchmark submission can be downloaded [[http://www.mat.unical.it/aspcomp2011/files/myproblem-aspteam-proposal.zip|here]]. | '''Remark''': checkers provided by benchmark authors will be used only for checking existing witnesses. It is not up to the benchmark author to check validity of other outputs like {{{NO ANSWER SET FOUND}}}. The source code of the correctness checker has to be be included in the package; moreover, the provided software must be able to (build and) run on the Debian i686 GNU/Linux(kernel ver. 2.6.26) operating system. A checker can be built on top of a logic specification for a solver of choice: in such a case binaries of the solver must be provided together with the checker encoding. === Problem Input-Output predicates and Instance Specification === In the following it is specified the allowed format for specifying input and output of problems and instances. Samples are available in the competition web site. ==== Problem Input and Output. ==== Benchmark problems specifications have to clearly indicate the vocabulary of input and output predicates, i.e., a list of predicate names for the input and a list of predicate names for the output and their arity in the usual logic programming notation (e.g. {{{p/2}}} denotes the binary predicate {{{p}}}). ==== Instance Specification. ==== Input instance are sequences of ''Facts'' (atoms followed by the dot "." character) with only predicates of the input vocabulary, possibly separated by spaces and line breaks, entirely saved in a text file (only one instance per file is allowed). <<Anchor(MAXINT-MAXLEVEL)>> ==== Maximum Integer and maximum function nesting level, ==== have to be provided in a per-instance basis. In particular, they are specified in the filename containing a given instance. We recall that instances must be named {{{XX-benchmark_name-MAXINT-MAXLEVEL.asp}}} where {{{XX}}} is the instance number, {{{MAXINT}}} is the maximum integer ({{{0}}} if not relevant), and {{{MAXLEVEL}}} is the maximum function nesting level ({{{0}}} if not relevant). ##==== Remark. ==== ##Recall that each ASP system (or solver script) will read an input instance (from standard input) and will produce an output (to standard ##output) according to the specifications for the input and output format of call scripts reported in the ''Competition Rules'' document. |
Problem specifications package format
Remark
For packages to be submitted via Easychair system: in case the size of the submitted package exceeds the allowed size limits, please just put an URL pointing to it.
Submission packages
Submitted problem specifications have to be packaged in a single compressed archive named benchmark_name-contributor_name.zip (or tar.gz) containing:
a benchmark_name.spec.txt file containing the textual problem description (a template is available, see below);
a benchmark_name.enc.asp file containing a proposed encoding for the problem (which must match the provided language classification);
a folder named checker containing the sources of a correctness checker together with a README.txt file containing the instructions for (possibly building and) running it;
a folder named samples containing some instances (one instance per text file).
benchmark_name and contributor_name should be substituted with their actual value. The provision of a checker at this stage is optional.
A template package for benchmark submissions is available here.
Finalized packages (for accepted problems only)
A finalized problem specification has to be packaged in a single compressed archive named benchmark_name-contributor_name.zip (or tar.gz) containing:
a benchmark_name.spec.txt file containing the textual problem description (a template is available, see below);
a benchmark_name.enc.asp file containing a proposed encoding for the problem (that must match the provided language classification);
a folder named checker containing the sources of a correctness checker together with a README.txt file containing suitable instruction for (building and) running it.
a folder named instances containing at least 50 numbered instances (one per file) named XX-benchmark_name-MAXINT-MAXLEVEL.asp where: XX is the instance number, MAXINT is the maximum integer (0 if not relevant), and the maximum function nesting level is MAXLEVEL (0 if not relevant), see Section Programs with Function symbols and integers;
In alternative to the point above, a folder named generator containing the sources of an instance generator together with a README.txt file containing suitable instruction for (building and) running it; such generator should be able to produce a number of instances according to naming given in point 4, above. Finally,
a demonstration.txt file in which the author provides sufficient arguments demonstrating that the benchmark problem can be effectively solved.
A template package for final benchmark submission is available here.
Checker format
The checker reads from standard input a witness in the prescribed format (see File and Language Format for details) and writes in standard output a single row of text containing the string OK (if the witness is correctly assessed as a solution), and the string FAIL otherwise. The string OK must be followed by a space-separated integer representing the witness cost in case of optimization problems. The checker outputs WARN and an exit code different from zero in all other cases (e.g. the witness is not syntactically correct, or the output NO ANSWER SET FOUND has been incorrectly piped towards the checker). Informative messages can be output in standard error.
Note that witnesses are assumed to be inclusive of both instance facts (input predicates) and solution facts (output predicates).
Remark: checkers provided by benchmark authors will be used only for checking existing witnesses. It is not up to the benchmark author to check validity of other outputs like NO ANSWER SET FOUND.
The source code of the correctness checker has to be be included in the package; moreover, the provided software must be able to (build and) run on the Debian i686 GNU/Linux(kernel ver. 2.6.26) operating system. A checker can be built on top of a logic specification for a solver of choice: in such a case binaries of the solver must be provided together with the checker encoding.
Problem Input-Output predicates and Instance Specification
In the following it is specified the allowed format for specifying input and output of problems and instances. Samples are available in the competition web site.
Problem Input and Output.
Benchmark problems specifications have to clearly indicate the vocabulary of input and output predicates, i.e., a list of predicate names for the input and a list of predicate names for the output and their arity in the usual logic programming notation (e.g. p/2 denotes the binary predicate p).
Instance Specification.
Input instance are sequences of Facts (atoms followed by the dot "." character) with only predicates of the input vocabulary, possibly separated by spaces and line breaks, entirely saved in a text file (only one instance per file is allowed).
Maximum Integer and maximum function nesting level,
have to be provided in a per-instance basis. In particular, they are specified in the filename containing a given instance. We recall that instances must be named XX-benchmark_name-MAXINT-MAXLEVEL.asp where XX is the instance number, MAXINT is the maximum integer (0 if not relevant), and MAXLEVEL is the maximum function nesting level (0 if not relevant).