Membership in Goal: Difference between revisions
imported>Billaude |
imported>Billaude |
||
Line 230: | Line 230: | ||
*<math>x\in A\binter dom(f),A\binter dom(f\bunion g)\subseteq B\quad\vdash\quad x\in B</math> | *<math>x\in A\binter dom(f),A\binter dom(f\bunion g)\subseteq B\quad\vdash\quad x\in B</math> | ||
*:the reason for the failure of the two last examples is that when union or intersection are compared, we should take all the expression containing each member, but we don't. | *:the reason for the failure of the two last examples is that when union or intersection are compared, we should take all the expression containing each member, but we don't. | ||
*<math>x\in A\cprod dom(B\ | *<math>x\in A\cprod dom(B\cprod C)\quad\vdash\quad x\in A\cprod B</math> | ||
*: it fails because when we get equivalent expression of the Cartesian product, we don't go further enough. | *:it fails because when we get equivalent expression of the Cartesian product, we don't go further enough. | ||
*:<math>\bigl(</math> where <math>op_1</math> and <math>op_2</math> are ones of :<math>\quad\rel, \trel, \srel, \strel, \pfun, \tfun, \pinj, \tinj, \psur, \tsur, \tbij\bigr)</math> | *:<math>\bigl(</math> where <math>op_1</math> and <math>op_2</math> are ones of :<math>\quad\rel, \trel, \srel, \strel, \pfun, \tfun, \pinj, \tinj, \psur, \tsur, \tbij\bigr)</math> | ||
[[Category:Design proposal]] | [[Category:Design proposal]] |
Revision as of 15:18, 19 August 2011
Objective
This page describes the design of the reasoner MembershipGoal and its associated tactic MembershipGoalTac.
This reasoner discharges sequent whose goal denotes a membership which can be inferred from hypotheses. Here an basic example of what it discharges :
Analysis
Such sequent are proved by PP and ML. But, these provers have both drawbacks :
- All the visible are added as needed hypotheses, which is most of the time not the case.
- They take quite consequent time to prove it (even with the basic example given here above, the difference in time execution is noticeable).
- If there are too many hypotheses, or if the expression of the is too complicated, they may not prove it.
This is particularly true when in the list of inclusion expressions of each side of the relation are not equal. For example :
Such a reasoner contributes to prove more Proof Obligations automatically, faster and with fewer needed hypotheses which makes proof rule more legible and proof replay less sensitive to modifications.
Design Decision
Tactic
This part explains how the tactic (MembershipGoalTac) associated to the reasoner MembershipGoal is working.
Goal
The tactic (as the reasoner) should works only on goals such as :
For examples :
In the latter case, the reasoner won't try to prove that x belongs to A and y belongs to B, but that the mapplet belong to the Cartesian product.
Hypotheses
Now we have to find hypotheses leading to discharge the sequent. To do so, the tactic recovers two kinds of hypotheses :
- the ones related to the left member of the goal (this is the start point):
- the ones denoting inclusion (all but the ones matching the description of the first point) :
Then, it will search a link between those hypotheses so that the sequent can be discharged.
Find a path
Now that we recovered all the hypotheses that could be useful for the reasoner, it remains to find a path among the hypotheses leading to discharge the sequent. Depending on the relations on each side of the inclusion, we will act differently. always represent an expression (may be a domain, a range, etc.).
- The following sequent is provable because .
- The following sequent is provable because .
- By keeping the notation we also deduce that :
- For some relations, positions are needed to be known to continue to find hypotheses, but it is not always necessary.
By using these inclusions it tries to find a path among the recovered hypotheses. Every one of those should only be used once, avoiding possible infinite loop . Among all paths that lead to discharge the sequent, the tactic give the first it finds.
Reasoner
This part describe how the reasoner MembershipGoal works.
Goal
First, it checks that the goal matches the description made in the part tactic : . Thus, we record the member x as well as the set S
Input
Then, it checks that the input is a hypothesesReasonerInput (an input with an array of predicates). Every given predicates must be contained in the sequent. Only one must be related to the goal's member so that there are no ambiguity. All the other ones must denote inclusion.
Find a path
With the same reasoning as for the tactic, we try to find a path leading to discharge the goal.
Trusted Base
At that point, the reasoner performs the same jobs as the tactic which is quite complicated. That poses one problem : it is hard to proof the reasoner is safe (only doing what it was meant to, not discharging sequent that cannot be proofed). Because reasoners are in the trusted base, we should be absolutely sure of what they perform. How to validate the found path ?
As we know, the reasoner condense several inferences rules in only one proof rule. To validate the found path, we have to validate every single inference rule. To achieve it, we use the class created in that purpose : Rules. Each rules contain one predicate and an array of rules (its antecedents). When the path is searched, the rule corresponding is created. When the path is found, we test if the predicate of the rule is equal to the goal. If not, it means the path found was incorrect, so the reasoner fails, else the sequent is discharged.
Example of rules :
Implementation
This section explain how the tactic has bee implemented.
Positions
As it was said, we may sometimes need the position. It is represented by an array of integer. Here are the possible values the array contains (atomic positions) :
- kdom : it corresponds to the domain.
- kran : it corresponds to the domain.
- converse : it corresponds to the child of an inverse
For example, the following expressions at the given positions are equivalent.
Some combinations of atomic positions are equivalent. In order to simplify comparison between positions, they are normalized :
Goal
A pair (expression ; position) is said to be contained in the goal if and only if exp is contained in the goal, and if the position matched of exp in the goal is equal to pos. For examples, let's see the annexe
Hypotheses
As explained in the design decision part, there are two kinds of hypotheses which are recovered. But when hypotheses related to the left member of the goal are stored, the position of x is also record. Then, if there is an hypothesis such as , then this hypothesis is mapped to the positions .
Find a path
Let's consider that following sequent : .
- From the goal we get two informations : the member which is x as well as the set we try to prove it belongs to which is A.
- By knowing x we recover hypothesis giving informations about it. In our study case, from the hypothesis we infer that x belong to at those possible positions
- Tactic : record all these informations
- Reasoner : We consider that the tactic will found the most complicated path. For each positions, we make the associated rule, which give in our example .
- Now, that we have a set to start the search of a path , we get all the expression containing it : . As we don't want to have expression such as dom(...), we modify the position.
- Tactic : Here, there are only the mapping between the positions and the expression :
- Reasoner : we generate the rule corresponding to the computed sets :
- We test if one of these pair is contained in the goal. If so, we move to the step 5. But it clearly appears that it is not the case. So, we try to find hypotheses among the one denoting inclusion which are related to that pair. We clearly see that the expression . Actually, we search every expressions containing m using that mapping . From we can say that only the domain of m is contained in it. Then it ensures this position is part of the position of m in which x belongs to. If so we remove that position and obtain a new mapping (more details here) and we step back to 3 with that new pair.
- Reasoner : the rule corresponding is generated
- We find a path, the works is done.
- Tactic : If a path has been found, then we call the reasoner with all the used predicates as input.
- Reasoner :At the end, we check that the generated rule is equal to the goal. If so, the sequent is discharged. Else, a failure is returned.
We see that the tactic may not find the most simple path to discharge the sequent. Moreover, there are some cases where the tactic is able to find a path but the reasoner is unable to prove it due to a weakness in the rules (see all the untreated cases). Example :
Depending on whether the tactic returns or , the reasoner will fail or succeed. To prevent such hazardous behavior, re-writing should be proceeded.
Annexe
Predicate | Position of g matched | Inferred predicate | Position in h |
---|---|---|---|
In the case a converse appears at the end of the position of g matched, it is removed, then, we test if the position is part of the position. If so, it is removed and converse is added at the beginning of the array (which is automatically normalized).
Untreated cases
Some cases are not treated. Further enhancement may be provided for some.
- as well as all the possibles re-writing.
-
- the last 12 examples fails because the Rules have some weakness. This show that some re-writing should be performed.
-
- the reason for the failure of the two last examples is that when union or intersection are compared, we should take all the expression containing each member, but we don't.
-
- it fails because when we get equivalent expression of the Cartesian product, we don't go further enough.
- where and are ones of :