SaturationProcedure
Related Docs:
object SaturationProcedure
| package theories
Type representing the cases in which the saturation procedure applies.
Type representing the cases in which the saturation procedure applies. Those could be formulas or terms occurring in a goal, etc.
Scheduled tasks of the saturation procedure.
Scheduled tasks of the saturation procedure. Each of those tasks takes care of one application point.
The priority of performing the given saturation.
The priority of performing the given saturation. Lower numbers represent higher priority.
Determine all points at which this saturation procedure could be applied in a goal.
Actions to be performed for one particular application point.
Actions to be performed for one particular application point. The method will be called exactly once for each persistent application point, i.e., for each application point that does eventually disappear as the result of some rule applications. The method should check whether the application point still exists in the goal; in case the application point has already disappeared from the goal at the point of calling this method, the method should return an empty sequence.
Axioms defining the theory; such axioms are simply added as formulae to the problem to be proven, and thus handled using the standard reasoning techniques (including e-matching).
Axioms defining the theory; such axioms are simply added as formulae to the problem to be proven, and thus handled using the standard reasoning techniques (including e-matching).
Optionally, other theories that this theory depends on.
Optionally, other theories that this theory depends on. Specified dependencies will be loaded before this theory, but the preprocessors of the dependencies will be called after the preprocessor of this theory.
Optionally, a function evaluating theory functions applied to concrete arguments, represented as constructor terms.
Optionally, a function evaluating theory functions applied to concrete arguments, represented as constructor terms.
Optionally, a function evaluating theory predicates applied to concrete arguments, represented as constructor terms.
Optionally, a function evaluating theory predicates applied to concrete arguments, represented as constructor terms.
A simplification function that applies the methods evalFun
and evalPred to some given expression (but not recursively).
A simplification function that applies the methods evalFun
and evalPred to some given expression (but not recursively).
This is used in the Theory.postSimplifiers methods.
Add the symbols defined by this theory to the order
Add the symbols defined by this theory to the order
Mapping of interpreted functions to interpreted predicates, used translating input ASTs to internal ASTs (the latter only containing predicates).
Mapping of interpreted functions to interpreted predicates, used translating input ASTs to internal ASTs (the latter only containing predicates).
Information which of the predicates satisfy the functionality axiom; at some internal points, such predicates can be handled more efficiently
Information which of the predicates satisfy the functionality axiom; at some internal points, such predicates can be handled more efficiently
Interpreted functions of the theory
Interpreted functions of the theory
If this theory defines any Theory.Decoder, which
can translate model data into some theory-specific representation,
this function can be overridden to pre-compute required data
from a model.
If this theory defines any Theory.Decoder, which
can translate model data into some theory-specific representation,
this function can be overridden to pre-compute required data
from a model.
Optionally, a post-processor that is applied to formulas output by the prover, for instance to interpolants or the result of quantifier elimination.
Optionally, a post-processor that is applied to formulas output by the
prover, for instance to interpolants or the result of quantifier
elimination. This method will be applied to the formula after
calling Internal2Inputabsy.
Optionally, a pre-processor that is applied to formulas over this theory, prior to sending the formula to a prover.
Optionally, a pre-processor that is applied to formulas over this theory, prior to sending the formula to a prover. This method will be applied very early in the translation process.
Check whether we can tell that the given combination of theories is sound for checking satisfiability of a problem, i.e., if proof construction ends up in a dead end, can it be concluded that a problem is satisfiable.
Check whether we can tell that the given combination of theories is sound for checking satisfiability of a problem, i.e., if proof construction ends up in a dead end, can it be concluded that a problem is satisfiable.
Optionally, a set of predicates used by the theory to tell the
PresburgerModelFinder about terms that will be handled
exclusively by this theory.
Optionally, a set of predicates used by the theory to tell the
PresburgerModelFinder about terms that will be handled
exclusively by this theory. If a proof goal in model generation mode
contains an atom p(x), for p in this set,
then the PresburgerModelFinder will ignore x
when assigning concrete values to symbols.
Optionally, a plug-in implementing reasoning in this theory
Optionally, a plug-in implementing reasoning in this theory
Predicate to record, in a proof goal, that a handler has been spawned for a certain application point.
Predicate to record, in a proof goal, that a handler has been spawned for a certain application point. This is done by assigning a unique id to every application point; the argument of this predicate is the id.
Optionally, simplifiers that are applied to formulas output by the prover, for instance to interpolants or the result of quantifier.
Optionally, simplifiers that are applied to formulas output by the
prover, for instance to interpolants or the result of quantifier. Such
simplifiers are invoked by ap.parser.Simplifier. By
default, this list will only include the evaluatingSimplifier.
Optionally, a post-processor that is applied to formulas output by the prover, for instance to interpolants or the result of quantifier elimination.
Optionally, a post-processor that is applied to formulas output by the
prover, for instance to interpolants or the result of quantifier
elimination. This method will be applied to the raw formulas, before
calling Internal2Inputabsy.
Information how interpreted predicates should be handled for e-matching.
Information how interpreted predicates should be handled for e-matching.
Interpreted predicates of the theory
Interpreted predicates of the theory
Optionally, a pre-processor that is applied to formulas over this theory, prior to sending the formula to a prover.
Optionally, a pre-processor that is applied to formulas over this theory, prior to sending the formula to a prover.
Optionally, a plugin for the reducer applied to formulas both before and during proving.
Optionally, a plugin for the reducer applied to formulas both before and during proving.
When instantiating existentially quantifier formulas,
EX phi, at most one instantiation is necessary
provided that all predicates in phi are contained
in this set.
When instantiating existentially quantifier formulas,
EX phi, at most one instantiation is necessary
provided that all predicates in phi are contained
in this set.
Additional axioms that are included if the option
+genTotalityAxioms is given to Princess.
Additional axioms that are included if the option
+genTotalityAxioms is given to Princess.
Dependencies closed under transitivity, i.e., also including the dependencies of dependencies.
Dependencies closed under transitivity, i.e., also including the dependencies of dependencies.
A list of functions that should be considered in automatic trigger generation
A list of functions that should be considered in automatic trigger generation
(Since version ) see corresponding Javadoc for more information.
Class to simplify the implementation of saturation procedures as part of theory plugins. A saturation procedure is a procedure waiting for patterns to occur in a proof goal (e.g., formulas of a certain shape), and can apply proof rules for every such occurrence. Saturation will be implemented by adding tasks to the task queue of every goal, so that the prover can globally schedule the different rules to be applied.
This procedure does not take into account that applications points might get rewritten during the proof process; e.g., a variable
xcould turn intoywhen the equationx = yappears. In such cases, the saturation rule could get applied repeatedly for the same point.