The CADE ATP System Competition
Design and Organization
This document contains information about the:
The rules, specifications, and deadlines given here are absolute.
Only the competition panel has the right to make exceptions.
It is assumed that all entrants have read the web pages related
to the competition, and have complied with the competition rules.
Non-compliance with the rules can lead to disqualification.
A "catch-all" rule is used to deal with any unforeseen circumstances:
No cheating is allowed.
The panel is allowed to disqualify entrants
due to unfairness, and to adjust the competition rules in case of misuse.
Every effort has been made to organize the competition in a fair and
No responsibility is taken if, for one reason or the other, your system
does not win.
The design and procedures of this CASC evolved from those of
Important changes for this CASC are:
- The THN division has been put into a hiatus state.
- Efficiency based on wall clock time will be provided in the results.
CASC is divided into divisions according to problem and system characteristics.
There are competition divisions in which systems are explicitly
ranked, and a demonstration division in which systems demonstrate
their abilities without being ranked.
Some divisions are further divided into problem categories, which
makes it possible to analyse, at a more fine grained level, which systems
work well for what types of problems.
The problem categories have no effect on the competition rankings, which
are made at only the division level.
The competition divisions are open to ATP systems that meet the required
Each division uses problems that have certain logical, language, and syntactic
characteristics, so that the ATP systems that compete in the division are, in
principle, able to attempt all the problems in the division.
The problems section explains what problems are
eligible for use in each division and category.
The system evaluation section explains how the
systems are ranked in each division.
- The THF division:
Typed Higher-order Form theorems (axioms with a provable conjecture).
The THF division has two problem categories:
- The TNE category: THF with No Equality
- The TEQ category: THF with EQuality
- The TFA division:
Typed First-order with Arithmetic theorems (axioms with a provable
The TFA division has three problem categories:
- The TFI category: TFA with only Integer arithmetic
- The TFR category: TFA with only Rational arithmetic
- The TFE category: TFA with only Real arithmetic
- The TFN division:
Typed First-order with arithmetic Non-theorems (axioms with a
countersatisfiable conjecture, and satisfiable axiom sets).
- The FOF division:
First-Order Form theorems (propositional, axioms with a provable
The FOF division has two problem categories:
- The FNE category: FOF with No Equality
- The FEQ category: FOF with EQuality
- The FNT division:
First-order form Non-Theorems (axioms with a countersatisfiable
conjecture, and satisfiable axiom sets).
The FNT division has two problem categories:
- The FNN category: FNT with No equality
- The FNQ category: FNT with eQuality
- The EPR division:
Effectively PRopositional clause normal form theorems and
non-theorems (clause sets).
Effectively propositional means that the problems are known to
be reducible to propositional problems, e.g., CNF problems that have no
functions with arity greater than zero.
The EPR division has two problem categories:
- The EPT category: Effectively Propositional Theorems
(unsatisfiable clause sets)
- The EPS category: Effectively Propositional
non-theorems (Satisfiable clause sets)
- The LTB division:
First-order form theorems (axioms with a provable conjecture) from
Large Theories, presented in Batches.
A large theory has many functors and predicates, and many axioms of
which typically only a few are required for the proof of a theorem.
Problems in a batch all use a common core set of axioms, and the
problems in a batch are given to the ATP system all at once.
The LTB division has three problem categories:
ATP systems that cannot run in the competition divisions for any reason
(e.g., the system requires special hardware, or the entrant is an organizer)
can be entered into the demonstration division.
Demonstration division systems can run on the competition computers, or on
computers supplied by the entrant.
The entry specifies which competition divisions' problems are to be used.
The demonstration division results are presented along with the competition
divisions' results, but might not be comparable with those results.
The systems are not ranked and no prizes are awarded.
The computers have:
Each ATP system runs one job on one CPU at a time.
Systems may use all the cores on the CPU.
- Four (a quad-core chip) Intel(R) Xeon(R) E5-2609, 2.40GHz CPUs
- 128GB memory
- The Red Hat Enterprise Linux Workstation release 6.3 (Santiago)
operating system, kernel 2.6.32-431.1.2.el6.x86_64
Problems for the non-LTB divisions are taken from the
TPTP Problem Library.
The TPTP version used for CASC is not released until after the competition
has started, so that new problems have not been seen by the entrants.
The problems have to meet certain criteria to be eligible for selection.
The problems used are randomly selected from the eligible problems based on
a seed supplied by the competition panel.
The problems are given to the ATP systems in TPTP format.
- The TPTP tags problems that designed specifically to be suited or
ill-suited to some ATP system, calculus, or control strategy as
biased, and they are excluded from the competition.
- The problems are syntactically non-propositional.
- The TPTP uses system performance data in the Thousands of Solutions
from Theorem Provers (TSTP) solution library to compute problem
difficulty ratings in the range 0.00 (easy) to 1.00 (unsolved).
Difficult problems with a rating in the range 0.21 to 0.99 are
eligible for CASC.
Problems of lesser and greater ratings might also be eligible
in some divisions if there are not enough problems with ratings in
Performance data from systems submitted by the system submission
deadline is used for computing the problem ratings for the TPTP
version used for the competition.
- The selection is constrained so that no division or category contains
an excessive number of very similar problems.
- The selection is biased to select problems that are new in
the TPTP version used, until 50% of the problems in each category have
been selected, after which random selection (from old and new problems)
The actual percentage of new problems used depends on how many new
problems are eligible and the limitation on very similar problems.
Problems for the LTB division are taken from publicly available problem sets:
the AIM problem category will use the
the CML problem category will use the
the HLL problem category will use the
Entrants are expected to honestly not use any of the (publicly available)
problems for tuning or training before the competition.
The problems in each category have a large number of common included
axiom files (the "common core set of axioms").
Systems can benefit from preloading and analyzing these common axioms once,
in advance of problem solving.
In order to facilitate and promote learning from previous proofs,
each problem category is accompanied by a set of training problems and
their solutions, which can be used for tuning and training during (typically
at the start of) the competition.
The training problems are not used in the competition.
In order to support learning, the problems in each category have consistent
symbol usage, and almost consistent axiom naming, between problems.
Number of Problems
The minimal numbers of problems that must be used in each division and
category, to ensure sufficient confidence in the competition results,
are determined from the numbers of eligible problems in each division
(the competition organizers have to ensure that there are sufficient computers
available to run the ATP systems on this minimal number of problems).
The minimal numbers of problems are used in determining the
time limits imposed on each solution attempt.
A lower bound on the total number of problems to be used is determined from
the number of computers available,
the time allocated to the competition,
the number of ATP systems to be run on the competition computers over all the
the time limit per problem,
according to the following relationship:
NumberOfComputers * TimeAllocated
NumberOfProblems = ---------------------------------
NumberOfATPSystems * TimeLimit
It is a lower bound on the total number of problems because it assumes that
every system uses all of the time limit for each problem.
Since some solution attempts succeed before the time limit is reached, more
problems can be used.
The numbers of problems used in each non-LTB division and problem category are
(roughly) proportional to the numbers of eligible problems, after taking
into account the limitation on very similar problems.
The numbers of problems used in each division and category are determined
according to the judgement of the competition organizers.
The problems are in TPTP format, with include directives.
The problems in each non-LTB division are given in increasing order of
TPTP difficulty rating.
The problems in the LTB division are given in the natural order
of their export.
In order to ensure that no system receives an advantage or disadvantage
due to the specific presentation of the problems in the TPTP, the problems
in the non-LTB divisions are preprocessed to:
- strip out all comment lines, including the problem header
- randomly reorder the formulae/clauses
(include directives are left before formulae,
type declarations and definitions are kept before the symbols' uses)
- randomly swap the arguments of associative connectives, and
randomly reverse implications
- randomly reverse equalities
In the LTB division the formulae are not preprocessed, thus
allowing the ATP systems to take advantage of natural structure that occurs
in the problems.
Batch Specification Files
The problems for each problem category of the LTB division are listed in a
batch specification file, containing global data lines and one or
more batch specifications.
The global data lines are:
Each batch specification consists of:
- A problem category line of the form
For the LTB division it will be
where the category mnemonics are
AIM, CML, and HLL.
- The name of a directory (relative to the directory holding the batch
specification file) that contains training data in the form
of problems in TPTP format and one or more solutions to each problem in
TSTP format, in a line of the form
The directory will contain a file
that expands in place to three directories: Axioms,
Problems, and Solutions.
Axioms contains all the axiom files that can be used in the
training and competition problems.
Problems contains the training problems.
Solutions contains a subdirectory for each of the
Problems, containing TPTP format solutions to the problem.
A (toy) example .tgz is
BatchSampleLTBHLL is an example.
TrainingData.HLL.tgz contains all
the files mentioned in that example.
- A header line % SZS start BatchConfiguration
- A specification of whether or not the problems in the batch must be
attempted in order is given, in a line of the form
For the LTB division it will be
i.e., systems may not start any attempt on a problem, including reading
the problem file, before ending the attempt on the preceding problem.
- A specification of what output is required from the ATP systems
for each problem, in a line of the form
where the available list values are the SZS values
Assurance, Proof, Model, and Answer.
For the LTB division it will be
- The wall clock time limit per problem, in a line of the form
A value of zero indicates no per-problem limit.
- The overall wall clock time limit (for the batch) is given in a line
of the form
- A terminator line % SZS end BatchConfiguration
- A header line % SZS start BatchIncludes
- include directives that are used in every problem.
Problems in the batch have all these include directives, and
can also have other include directives that are not listed here.
- A terminator line % SZS end BatchIncludes
- A header line % SZS start BatchProblems
- Pairs of problem file names (relative to the directory holding the batch
specification file), and output file names where the output for the
problem must be written.
UPDATE: The output files must be written in the directory specified
as the second argument to the starexec_run script (the first
argument is the name of the batch specification file).
- A terminator line % SZS end BatchProblems
CPU and wall clock time limits are imposed.
The minimal CPU time limit per problem is 240s.
The maximal CPU time limit per problem is determined using the relationship
used for determining the number of problems, with the minimal number of
problems as the NumberOfProblems.
The CPU time limit is chosen as a reasonable value within the range allowed,
and is announced at the competition.
The wall clock time limit is imposed in addition to the CPU time limit, to
limit very high memory usage that causes swapping.
The wall clock time limit per problem is double the CPU time limit.
An additional memory limit is imposed, depending on the
The limits are imposed individually on each solution attempt.
In the demonstration division, each entrant can choose to use either a
CPU or a wall clock time limit, whose value is the CPU time limit of the
For each batch there is a wall clock time limit per problem, which is
provided in the configuration section at the start of each batch.
The minimal wall clock time limit per problem is 30s.
For each problem category there is an overall wall clock time limit, which is
provided in the configuration section at the start of each batch, and
is also available as a command line parameter.
The overall limit is the sum over the batches of the batch's per-problem
limit multiplied by the number of problems in the batch.
Time spent before starting the first problem of a batch (e.g., preloading
and analysing the batch axioms), and times spent between
ending a problem and starting the next (e.g.,
learning from a proof just found), are not part of the times taken on the
individual problems, but are part of the overall time taken.
There are no CPU time limits.
For each ATP system, for each problem, four items of data are recorded:
whether or not the problem was solved,
the CPU time taken,
the wall clock time taken,
and whether or not a proof or model was output.
In the LTB division, the wall clock time is the time from when
the system reports starting on a problem and reports
ending on a problem - the time spent before starting the first problem,
and times spent between ending a problem and starting the next, are not part
of the time taken on problems.
The systems are ranked in the competition divisions, from the performance data.
The THF, TFA, FOF, FNT, and LTB divisions are ranked according to the number
of problems solved with an acceptable proof/model output.
The TFN and EPR divisions are ranked according to the number of
problems solved, but not necessarily accompanied by a proof or model
(but systems that do output proofs/models are highlighted in the presentation
Ties are broken according to the average time taken over problems solved
(CPU time for non-LTB divisions, wall clock time for the LTB division).
In the competition divisions winners are announced and prizes are
The competition panel decides whether or not the systems' proofs and models are
The criteria include:
In addition to the ranking criteria, other measures are made and presented
in the results:
- Derivations must be complete, starting at formulae from the problem,
and ending at the conjecture (for axiomatic proofs) or a false
formula (for proofs by contradiction, including CNF refutations).
- For proofs of FOF problems by CNF refutation, the conversion from
FOF to CNF must be adequately documented.
- Derivations must show only relevant inference steps.
- Inference steps must document the parent formulae, the inference rule
used, and the inferred formula.
- Inference steps must be reasonably fine-grained.
- An unsatisfiable set of ground instances of clauses is acceptable for
establishing the unsatisfiability of a set of clauses.
- Models must be complete, documenting the domain, function maps,
and predicate maps.
The domain, function maps, and predicate maps may be specified by
explicit ground lists (of mappings), or by any clear, terminating
- The state-of-the-art contribution (SOTAC) quantifies the unique
abilities of each system.
For each problem solved by a system, its SOTAC for the problem is the
inverse of the number of systems that solved the problem.
A system's overall SOTAC is its average SOTAC over the problems it solves.
- The core usage is the average of the ratios of CPU time to
wall clock time used, over the problems solved.
This measures the extent to which the systems take advantage the
- The efficiency measure balances the number of problems solved
with the time taken.
It is the average of the inverses of the times for problems solved
multiplied by the fraction of problems solved.
This can be interpreted intuitively as the average of the solution rates
for problems solved, multiplied by the fraction of problems solved.
Efficiency is computed for both CPU time and wall clock time, to measure
how efficiently the systems use one core and how efficiently systems
use the multiple cores, respectively.
At some time after the competition, all high ranking systems in the
competition divisions are tested over the entire TPTP.
This provides a final check for soundness (see the section on
system properties regarding soundness
checking before the competition).
If a system is found to be unsound during or after the competition, but
before the competition report is published, and it cannot be shown that the
unsoundness did not manifest itself in the competition, then the system
is retrospectively disqualified.
At some time after the competition, the proofs and models from the winners
(of divisions ranked by the numbers of proofs/models output) are checked
by the panel.
If any of the proofs or models are unacceptable, i.e., they are significantly
worse than the samples provided, then that system is retrospectively
All disqualifications are explained in the competition report.
To be entered into CASC, systems must be registered using the
CASC system registration form.
No registrations are accepted after the
For each system entered, an entrant must be nominated to handle all issues
(including execution difficulties) arising before and during the competition.
The nominated entrant must
formally register for CASC.
It is not necessary for entrants to physically attend the competition.
Systems can be entered at only the division level, and can be entered
into more than one division.
A system that is not entered into a competition division is assumed to
perform worse than the entered systems, for that type of problem -
wimping out is not an option.
Entering many similar versions of the same system is deprecated, and entrants
may be required to limit the number of system versions that they enter.
Systems that rely essentially on running other ATP systems without adding
value are deprecated; the competition panel may disallow or move such
systems to the demonstration division.
The division winners of the previous CASC
are automatically entered into their divisions, to provide benchmarks
against which progress can be judged.
Prover9 2009-11A is automatically entered into the FOF division, to provide
a fixed-point against which progress can be judged.
A system description must be provided for each ATP system entered, using
this HTML schema.
The schema has the following sections:
- Architecture. This section introduces the ATP system, and describes
the calculus and inference rules used.
- Strategies. This section describes the search strategies used, why
they are effective, and how they are selected for given problems.
Any strategy tuning that is based on specific problems' characteristics
must be clearly described (and justified in light of the
- Implementation. This section describes the implementation of the ATP
system, including the programming language used, important internal
data structures, and any special code libraries used.
The availability of the system is also given here.
- Expected competition performance. This section makes some
predictions about the performance of the ATP system in each of the
divisions and categories in which it is competing.
The system description must be emailed to the competition organizers by
the system description deadline.
The system descriptions form part of the competition proceedings.
For systems in the division that require proof/model output, representative
sample solutions must be emailed to the competition organizers by the
sample solutions deadline.
Use of the TPTP format for
interpretations is encouraged.
The competition panel decides whether or not proofs and models are
Proof/model samples are required as follows:
An explanation must be provided for any non-obvious features.
Entrants must ensure that their systems execute in a competition-like
environment, and have the following properties.
Entrants are advised to finalize their installation packages and check these
well in advance of the system delivery deadline.
This gives the competition organizers time to help resolve any difficulties
Soundness and Completeness
- Systems must be sound.
At some time before the competition all the systems in the competition
divisions are tested for soundness.
Non-theorems are submitted to the systems in the
THF, TFA, FOF, EPR, and LTB
divisions, and theorems are submitted
to the systems in the TFN, FNT and EPR divisions.
Finding a proof of a non-theorem or a disproof of a theorem indicates
If a system fails the soundness testing it must be repaired by
the unsoundness repair deadline or be
For systems running on computers supplied by the entrant in the
demonstration division, the entrant must perform the soundness testing
and report the results to the competition organizers.
- Systems do not have to be complete in any sense, including
calculus, search control, implementation, or resource requirements.
- All techniques used must be general purpose, and expected to extend
usefully to new unseen problems.
The precomputation and storage of information about individual TPTP
problems or their solutions is not allowed.
Strategies and strategy selection based on individual problems
or their solutions are not allowed.
If machine learning procedures are used, the learning must ensure that
sufficient generalization is obtained so that no there is no
specialization to individual problems or their solutions.
- The LTB training problems and solutions may be used for producing
generally useful strategies that extend to other problems in the
Such strategies can rely on the consistent naming of symbols and
formulas in the problem sets, and may use techniques for
memorization and generalization of problems and solutions in the
The system description must fully explain any such tuning or
training that has been done.
Precomputation and storage of information about other problems in the
LTB problem sets, or their solutions, is not allowed.
- The competition panel may disqualify any system whose tuning or
training is deemed to be problem specific rather than general purpose.
If you are in doubt, contact the competition organizer.
- The system's performance must be reproducible by running the system again.
- Systems that cannot run on the competition computers can
be entered into the demonstration division.
- Systems must be fully automatic, i.e., all command line switches have
to be the same for all problems/problem batches in each division.
- In the LTB division the systems must attempt the problems in each batch
in the order given in the batch specification file.
Systems may not start any attempt on a problem, including reading the
problem file, before ending the attempt on the preceding problem.
- In the non-LTB divisions all solution output must be to stdout.
In the LTB division all solution output must be to the named output
file for each problem.
- In the LTB division the systems must print SZS notification lines to
stdout when starting and ending work on a problem (including
any cleanup work, such as deleting temporary files).
% SZS status Started for /home/graph/tptp/TPTP/Problems/CSR/CSR075+2.p
... (system churns away, result and solution output to file)
% SZS status Theorem for /home/graph/tptp/TPTP/Problems/CSR/CSR075+2.p
% SZS status Ended for /home/graph/tptp/TPTP/Problems/CSR/CSR075+2.p
- For each problem, the system must output a distinguished string
indicating what solution has been found or that no conclusion has been
Systems must use the
SZS ontology and standards for this.
% SZS status Theorem for SYN075+1
% SZS status GaveUp for SYN075+1
In the LTB division this line must be the last line output before the
ending notification line (the line must also be output to the output
- When outputting proofs/models, the start and end of the proof/model must
be delimited by distinguished strings.
Systems must use the
SZS ontology and standards for this.
% SZS output start CNFRefutation for SYN075+1
% SZS output end CNFRefutation for SYN075+1
The string specifying the problem status must be output before the start
of a proof/model.
Use of the TPTP format for
interpretations is encouraged.
- Systems that run on the competition computers must be
interruptible by a SIGXCPU signal, so that the CPU time limit
can be imposed, and interruptable by a SIGALRM signal,
so that the wall clock time limit can be imposed.
For systems that create multiple processes, the signal is sent first to
the process at the top of the hierarchy, then one second later to all
processes in the hierarchy.
The default action on receiving these signals is to exit (thus complying
with the time limit, as required), but systems may catch the signals
and exit of their own accord.
If a system runs past a time limit this is noticed in the timing
data, and the system is considered to have not solved that problem.
- If a system terminates of its own accord, it may not leave any
temporary or intermediate output files.
If a system is terminated by a SIGXCPU or SIGALRM,
it may not leave any temporary or intermediate output files anywhere other
than in /tmp.
- For practical reasons excessive output from an ATP system is not
A limit, dependent on the disk space available, is imposed on the amount
of output that can be produced.
For systems in the non-LTB divisions, entrants must email a
StarExec installation package to the competition organizers by the
system delivery deadline.
The installation package must be a .tgz file containing
only the components necessary for running the system (i.e., not including
source code, etc.).
The entrants must also email a .tgz file containing the source
code and any files required for building the StarExec installation package
to the competition organizers by the system delivery
For systems running on entrant supplied computers in the demonstration
division, entrants must email a .tgz file containing the source code
and any files required for building the executable system to the competition
organizers by the system delivery deadline.
After the competition all competition division systems' source code
is made publicly available on the CASC web site.
In the demonstration division, the entrant specifies whether or not
the source code is placed on the CASC web site.
An open source license is
Execution of the ATP systems is controlled by StarExec.
The jobs are queued onto the computers so that each CPU is running
one job at a time.
All attempts at the Nth problems in all the divisions and categories
are started before any attempts at the (N+1)th problems.
A system has solved a problem iff it outputs its termination string within
the time limit, and a system has produced a proof/model iff it outputs
its end-of-proof/model string within the time limit.
The result and timing data is used to generate an HTML file, and a web
browser is used to display the results.
The execution of the demonstration division systems is supervised by
- Check: You can
login to StarExec. If not,
apply for an account in the TPTP community.
- Check: You can access the TPTP space. If not,
email the competition organizers.
- Check: You can create and upload a
StarExec installation package.
The competition organizers have examplar StarExec installation packages
that you can use as a starting point - email the competition organizers
to get one that is appropriate for your ATP system.
- Check: You can create a job and run it, and your ATP system gets the
Use the SZS post processor.
- Check: Your ATP system can solve a problem that has include
Because of the way StarExec runs jobs, your ATP system must implement
the TPTP requirement ... "Include files with relative path names are
expected to be found either under the directory of the current file,
or if not found there then under the directory specified in the
TPTP environment variable."
- Check: You can email your StarExec installation package to the
competition organizer for testing.