Proof Manager: Difference between revisions
imported>Son No edit summary |
imported>Son No edit summary |
||
Line 3: | Line 3: | ||
Proof obligations are generated by the proof obligation generator and have the form of ''sequents''. | Proof obligations are generated by the proof obligation generator and have the form of ''sequents''. | ||
The Proof Manager architecture is separated into two parts: ''extensible'' part and ''static'' part. The extensible part is responsible for generating individual proof rules. The static part is responsible for putting proof rules together to construct and manage proofs. We call components that generate valid proof rules ''reasoners''. | |||
The basic reasoning capabilities of the Proof Manager can be extended by adding new reasoners. A reasoner may implement a decision procedure for automated proof, or a derived rule schema for interactive proof. | The basic reasoning capabilities of the Proof Manager can be extended by adding new reasoners. A reasoner may implement a decision procedure for automated proof, or a derived rule schema for interactive proof. | ||
By applying the generated proof rules by different reasoner, the Proof Manager builds a (partial) proof for an proof obligation by constructing ''proof trees''. | By applying the generated proof rules by different reasoner, the Proof Manager builds a (partial) proof for an proof obligation by constructing ''proof trees''. | ||
== Sequents == | == Sequents == | ||
Line 27: | Line 28: | ||
An important point about reasoners is that the internal workings of them are not visible to the other part of the Proof Manager. It is only required that they satisfy the following requirements: | An important point about reasoners is that the internal workings of them are not visible to the other part of the Proof Manager. It is only required that they satisfy the following requirements: | ||
1. '''Logically Valid''' A generated proof rule must be valid (i.e. can be derived) in the mathematical logic. | |||
2. '''Replayable''' A reasoner must work ''deterministically'', i.e. given the same input, a reasoner must generate the same proof rule every time. | |||
== Proof Trees == | == Proof Trees == | ||
Proof Trees are recursive structure based on ''Proof Tree Nodes''. Each node has three components: | |||
1. ''sequent'' A sequent. | |||
2. ''rule'' A proof rule (possibly ''null'') | |||
3. ''children'' A list of proof tree nodes (possibly ''null'' or ''empty''). | |||
A proof tree is a proof tree node where its sequent corresponding to the proof obligation. | |||
A proof tree node has different statuses: | |||
a. '''Pending''' No rule applied to this node, i.e. ''rule'' is ''null''. In this case, ''children'' must be ''null''. | |||
b. '''Not pending''' Has a rule applied to this node. In this case, ''children'' contains the list of child proof tree nodes. |
Revision as of 13:49, 10 September 2008
The Proof Manager is responsible for constructing proofs and maintaining existing proofs associated with proof obligations.
Proof obligations are generated by the proof obligation generator and have the form of sequents.
The Proof Manager architecture is separated into two parts: extensible part and static part. The extensible part is responsible for generating individual proof rules. The static part is responsible for putting proof rules together to construct and manage proofs. We call components that generate valid proof rules reasoners.
The basic reasoning capabilities of the Proof Manager can be extended by adding new reasoners. A reasoner may implement a decision procedure for automated proof, or a derived rule schema for interactive proof.
By applying the generated proof rules by different reasoner, the Proof Manager builds a (partial) proof for an proof obligation by constructing proof trees.
Sequents
Sequents are of the following form
H |- G
where H is the set of hypotheses (predicates) and G is the goal (a predicate in the mathematical language).
Reasoners
Reasoners are responsible for generating proof rules. The input of a reasoner is:
1. A sequent.
2. Optional input (e.g. a predicate in the case of the Cut Rule).
The output of the reasoner (in case of successful) is a proof rule. This proof rule is trusted by the Proof Manager to built the proof.
An important point about reasoners is that the internal workings of them are not visible to the other part of the Proof Manager. It is only required that they satisfy the following requirements:
1. Logically Valid A generated proof rule must be valid (i.e. can be derived) in the mathematical logic.
2. Replayable A reasoner must work deterministically, i.e. given the same input, a reasoner must generate the same proof rule every time.
Proof Trees
Proof Trees are recursive structure based on Proof Tree Nodes. Each node has three components:
1. sequent A sequent.
2. rule A proof rule (possibly null)
3. children A list of proof tree nodes (possibly null or empty).
A proof tree is a proof tree node where its sequent corresponding to the proof obligation.
A proof tree node has different statuses:
a. Pending No rule applied to this node, i.e. rule is null. In this case, children must be null.
b. Not pending Has a rule applied to this node. In this case, children contains the list of child proof tree nodes.