Semantic Tableau Prover for Modal Logic

Transcription

1 University of Manchester Third Year Project 2015 Semantic Tableau Prover for Modal Logic Student: Silviu Adi Pruteanu Supervisor: Dr. Renate Schmidt 1/34

2 Abstract This project report documents the extension of a Tableau Based Theorem Prover. The original system covers the operators of modal logic. The aim of the project is to extend the prover with multi-modal operators, frame conditions and blocking. All the main aims have been implemented and tested and there is only a small number of changes in the design of the original prover. Testing has revealed that the new system is slightly slower on short formulas and faster on long formulas that require a high number of operator expansions. 2/34

3 Acknowledgements I would like to take this opportunity to express my gratitude to those whose support has been invaluable to me throughout this project. To Dr. Renate Schmidt, my project supervisor, for providing excellent guidance on how to handle both the project and other issues. To Ruchika Mhaprolkar, for encouraging me to keep my spirits up during the more difficult parts of the project. And to my parents, for understanding my need for more privacy during the development of the project. 3/34

4 Contents 1 Introduction Background Modal Logic Multi-modal Logic Blocking Requirements analysis Existing System Extensions to the system Design The existing design Changes in the design Implementation Multi-modal Operators Frame Conditions Blocking Backtracking Code changes and Bug Fixes Results Input Output Testing Unit testing Blocking testing Prover testing Conclusion References /34

5 List of Figures Figure 2.1 Example of statement translated to logical formula... 8 Figure 2.2 Example of logical formula with operator... 8 Figure 2.3 Rules for proving the and operators... 9 Figure 2.4 Example of ϕ extending infinitely because of transitivity Figure 2.5 The Congruence Closure System Figure 2.6 Example of rewrite that shortens the proving time Figure 2.7 Example of rewrite causing a contradiction Figure 3.1 A model for the formula " a" Figure 3.2 The Tableau Prover's expansion rules Figure 3.3 The two types of Tableau Lines from Hanah Anderson's prover Figure 4.1 The main parts of Hanah Anderson's Tableau Prover Figure 4.2 The context free grammar for the parser Figure 4.3 The Main Window of the Tableau Prover Figure 4.4 The Three ways of to Add a Formula Figure 4.5 The Tableau Window of Hanah Anderson's Prover Figure 4.6 C rule line in the derivation Figure 4.7 An extended model that includes C rule information Figure 4.8 The extended derivation lines Figure 4.9 The redesigned Tableau Window Figure 5.1 Modal and multi-modal being expanded Figure 5.2 Transitive and Euclidean relations Figure 5.3 The Orientation, Deletion, Extension and Simplification rules Figure 5.4 The Deduction, Compression and Composition rules Figure 6.1 Screenshots of the two ways to parse a formula Figure 6.2 Screenshot of the Tableau Window Model Figure 6.3 Screenshot of Derivation and Frame Conditions Figure 7.1 The files for all the tests Figure 7.2 Speed of the prover with and without blocking /34

6 Chapter 1 Introduction 1.1 Aims and Objectives In logic, a software that is used in order to discover if a logical formula can be true (is satisfiable) is known as a Theorem Prover. This project aims to develop a Tableau Based Theorem Prover that can be used to prove any formula that contain modal and multi-modal operators. The final artefact is an extension of an already existing Tableau Based Theorem Prover. The basic prover already works for the logical formulae that use modal logic operators. The features that were expected to be added to the prover are the following: in addition to the already existing modal operators, multi-modal operators must be available the relations must be allowed to have frame conditions so that more relations can be created based on proprieties of already existing ones blocking must be introduced into the system to ensure that the prover returns a result The base prover is one developed by Hanah Anderson, a former student at the University of Manchester, as her third year project. [2] was used mainly for understanding the program, however, it was also used as a source of background reading to better understand how all the operators work. Blocking is achieved using the congruence closure system described in [1]. The overall strategy for blocking is unrestricted blocking. The first step towards achieving unrestricting blocking is the implementation of the much simpler parent blocking. This report covers the theory behind the features that must be added to the prover, the implementation of those features and the changes that had to be made in order for the system to work. Some information on what the best and worst parts of what the starting prover does is also provided. 6/34

7 1.2 Summary of chapters There are eight chapters to this report. Their contents are as follows: Chapter 2: Background This chapter explains the theory behind modal logic and blocking. It contains information about modal and multi-modal operators and how they differ to each other, why blocking is needed and how it is achieved. Chapter 3: Requirements analysis This chapter presents the original prover in detail. It covers how it works, the tools used as well as its limitations. This chapters also covers what changes needed to be made to the original prover. Chapter 4: Design This chapter covers the design aspects of the prover. First the design of the original prover is covered. Afterwards, the necessary and optional changes in the design are explained. Chapter 5: Implementation This chapter covers how the changes to the original system were coded. There is an explanation on how the new features work with the overall system as well as what changes were made in the old prover. This chapter also explains the bugs encountered during the development of the prover. Chapter 6: Results This chapter present how the completed system works. Using an example, the new features are presented. This chapter also serves as a guide on how the artefact is used. Chapter 7: Testing This chapter covers the tests performed on the system. The main information is on the tests performed on the new features. There is also a comparison between the performance of the system when the new features are used to when they are not used. Chapter 8: Conclusion This chapter summarises what was achieved during this project. The extent to which every desired feature was added is described here. There is also a description on what future work can be performed on this project and in what order it is best to perform the work. 7/34

8 Chapter 2 Background 2.1 Modal Logic In logic, a statement or a collection of statements is translated into a logical formula in order to determine if the statement is true or false. A logical formula can be a single variable whose value alone determines how the statement is evaluated, or it can be a collection of variables and logical operators [3]. Figure 2.1 Example of statement translated to logical formula For simple statements, the logical operators found in propositional logic (e.g.,, ) are sufficient in order to find a formula that translates to the statement (see Figure 2.1). However, in order to translate statements that include modality (e.g. "Sometimes" it is raining), propositional logic is extended to include modal operators (see Figure 2.2). This extended propositional logic is called modal logic and its operators are all the operators of propositional logic (i.e.,,,, ) with the added and operators. Figure 2.2 Example of logical formula with operator In modal logic, the formula will be proven within a world, a state or context in which the statement applies. What makes the and operators different from the propositional logic operators is that their sub-formulas need to be proven in separate worlds, that are related to the world in which the or is in. 2.2 Multi-modal Logic Modal logic, as an extension to propositional logic, has introduces two main concepts: the formula belongs to a state, called a world or a constant; and the and operators are used to introduce sub-formulas into other worlds. Regardless of modality the two operators will be proven in the same way by the prover. 8/34

9 Figure 2.3 Rules for proving the and operators A formula or sub-formula is true, if there exists a world, related to the one in which the is being proven, such that the 's sub-formula is true in that world. When a prover has to prove a formula, it will create a new world, then it will create a relation between the world the is in and the new world, and try to prove the sub-formula of the in that new world. Figure 2.3 shows the rules for expanding and operators. A formula or sub-formula is true, if for every relation from the 's world the 's sub-formula is true in the other world of the relation (this applies even if a relation is from a world to itself). When a prover has to prove a formula, it will try to prove the sub-formula in every world that fits the condition mentioned earlier. Also, if in the 's world a must then be proven, when the 's proving creates a new world, the 's sub-formula must be proven in this new world as well (see Figure 2.3). In multi-modal logic the operators have the same function as in as in modal logic with one additional condition. In multi-modal logic there can be multiple and operators each with an identifier. In multi-modal logic, when a formula is being proven the process is still the same, but the relation will have an identifier that matches the one of the that is being proven. When a formula is being proven, the only relations that are used must also have the same identifier as the. 2.3 Blocking Because the and operators rely on relations in order to be proven true or false, computing the truth value of a long formula becomes a more difficult problem when the relations have proprieties (e.g. reflexivity, symmetry, transitivity) that create even more relations. For some formulas, the relation proprieties can cause the process of solving to never terminate due to the dependencies between relations and the and operators. Blocking is the process of stopping a prover from extending infinitely while trying to prove some modal operator. Blocking is most needed when frame conditions apply to relations, as a formula or sub-formula of the form ϕ can cause a prover to extend infinitely, if relations are created between the 's world and the 's world. Figure 2.4 is just one example in which the prover would not terminate without blocking because of the ϕ that creates a new world for the operator. 9/34

10 Figure 2.4 Example of ϕ extending infinitely because of transitivity Examples of how the congruence closure rules are used to achieve unrestricted blocking are given in [1]. With congruence closure, blocking is achieved by rewriting occurrences of new states into already existing states. This way, if a sub-formula must be proven in the new state but an old state already has proven the sub-formula, then the rewrite will stop a sub-formula from needing to be proven a second time. This stops the prover form creating an infinite amount of worlds while attempting to prove a formula. Figure 2.5 shows the rules of the congruence closure system. Figure 2.5 The Congruence Closure System In modal logic, a rewrite of one world into another is done by using a C rule. A C rule is writhen as a pair of worlds, with the first world being the one that is rewritten to the second world (e.g. CRule (W1 W0) or {t c} in Figure 2.5 ). When a C rule is applied, all the lines that contained the first world of the C rule now are rewritten with the second line instead. C rules can be used to merge any two worlds at any point, however, the proof time is much shorter if 10/34

11 the merger is attempted earlier (so sub-formulas are not proven twice when they can be proven once). Blocking has a side benefit of shortening the time it takes to prove some formulas. If a formula has two or more sub-formulas what are the same, but in different worlds, the rewrite of one world to the other allows the prover to shorten the proving time by only proving the two sub-formulas once. Figure 2.6 shows how the proving time is shortened by only proving φ only once. Figure 2.6 Example of rewrite that shortens the proving time A disadvantage of blocking is that time may be wasted if rewrites cause contradictions and must be undone. If there is the case that, for any two worlds, a sub-formula is true in one world and it's negation is true in another, then the rewrite of the one world to the other will cause a contradiction between the two sub-formulas. Figure 2.7 shows a C rule causing a contradiction because φ and φ are now in the same world. Figure 2.7 Example of rewrite causing a contradiction When a world is rewritten, it is usually rewritten to a world that was created earlier in the proof. If all rewrites are to the root world (the world in which the overall formula must be proven and which was created earliest of all), then, for long formulas, the high number of sub-formulas increases the chance of contradictions appearing. Another rewrite strategy is to rewrite a new world to the world whose formula created the new world. This blocking strategy is known as parent merging. 11/34

12 Unrestricted blocking uses the congruence closure rules in order to rewrite as many worlds as possible. If a rewrite fails, then,for the world that was originally rewritten, there will be another attempted merger to another viable world. A viable world is any world that was created earlier during the proof and to which this rewrite was not attempted before. Unrestricted blocking attempts to maximise on the advantages of blocking and have as few separate worlds as possible. 12/34

13 Chapter 3 Requirements analysis 3.1 Existing System The final prover is made from an already existing prover. The starting prover was made by Hanah Anderson, as her third year project. It has rules to prove the operators of propositional logic as well as the and operators but not multi-modal operators. The relations created by this prover serve only to identify the dependencies between the worlds (R(s, t) means that for a is in world s, that 's sub-formula is in world t). When the prover receives a formula, it first simplifies it into negation normal form (NNF). After that the prover will try to find a model for the NNF formula. The model comprises the conditions that must be satisfied for the formula to be satisfiable. Hanah Anderson's model has information on worlds that must exist, the relations between those worlds and what atomic sub-formulae must be true in each world. Figure 3.1 is a screenshot of a model as seen in the original prover. Figure 3.1 A model for the formula " a" A model is found by expanding each sub-formula according to their respective expansion rules. The expansion rules are called alpha (α) for conjunction, beta (β) for disjunction, gamma (γ) for and sigma (σ) for (see Figure 3.2). Implication and equivalence do not have expansion rules, as they are simplified in NNF. The formula and all sub-formulas are written by the prover as lines from which a tree tableau can be built. 13/34

14 Figure 3.2 The Tableau Prover's expansion rules If all sub-formulas have been expanded and no contradictions exists, the formula is satisfiable, and a model is returned to the GUI along with the derivation of the formula. If contradictions exist the prover will backtrack to a disjunction that causes the contradiction (because of its subformula's expansion) and expand that disjunction differently. If no such disjunction exists, the formula is not satisfiable and the prover will return a derivation that shows this. The derivation is a collection of the steps that were taken in order to find a model for the formula. The derivation is made of the tableau lines that were created by expanding the overall formula. The derivation contains all the information presented in the model and, if the prover reached a contradiction(s) while looking for a model, it also contains information on how the contradiction was reached. The derivation has a structure that is sufficiently detailed in order to be able to construct the tree from all the tableau lines. If the line is for a formula the structure is: "line number. [world: formula] derived from(d){ [what line number], what rule (e.g. alpha, beta, sigma)} expands to(e){[what lines number]} conflicts with(c) {[what line number]} expanded explored (if the line has been expanded)". For lines that show a relation the structure does not have a world, as relations are used to show connections between worlds and are not associated with a single world, nor does it expand to any other line or conflict with any other line (see Figure 3.3). Figure 3.3 The two types of Tableau Lines from Hanah Anderson's prover "Conflicts with" is used to show places where the formula is proven to be a contradiction. When a sub-formula contradicts another, a line is created that has the formula "FALSE" and derivation 14/34

15 rule "closure". This is used to show the two lines are cannot be true at the same time. When a "FALSE" line is created, the prover has to find a line that contains a disjunction whose expansion indirectly causes the contradiction. If such a disjunction can be expanded differently the prover will expand the disjunction in a different way, and the contradiction along with the previous expansion is not considered in the model anymore. 3.2 Extensions to the system There are three main extension that must be made to the system: users must be able to use multi-modal operators, relations must have frame conditions from which more relations can be created and blocking must be implemented to ensure that the prover terminates. Additionally, they extended prover must keep all the functionality of the original prover and must be created in a way that permits future extensions or alteration to be possible. Finally, Dr. Renate has requested that the rule for expanding the should be called delta not sigma and will be changed accordingly. The operators of the original prover are objects. For each operator object the prover has some function capable of expanding the formula or sub-formula in order to find a model. The multimodal operators must be inserted into the system in the same way in order to allow anyone who will extend the system to easily understand how this extension was implemented. The only relation creating function in the original prover is the function expanding a formula. This fact means that frame conditions cannot inserted in a way that someone building on the final artefact can understand without looking at the code for the function. However, if the function is made simple enough to understand, this extension will not be too troublesome. The biggest problem is blocking. Unlike anything else in the system, blocking relies on changing existing lines, not just creating new ones. For this to be understood there should be a clear way of showing that a line is not how it was originally created, but that it was changed at some point by blocking. 15/34

16 Chapter 4 Design 4.1 The existing design The overall artefact has four main parts. There is a GUI that takes a logical formula in the form of a string. The string is then given to a parser, where it is converted into a logical formula and returned to the GUI. The logical formula is then passed to a pre-processor, where the formula is converted into its negation normal form (NNF) equivalent. Then a tableau is made from the NNF formula in order to find if the formula is true. The result of the tableau is then shown by the GUI. Figure 4.1 The main parts of Hanah Anderson's Tableau Prover In the Main Window, the GUI has a button called "Add Formula", from which the formula can be introduce in one of three methods. The formula can be entered as text into a file and the file path given to the GUI. Alternatively, the formula can be entered into a text box. If the formula is introduced this way it will be saved into a file and the GUI will use the first method on the file path. Figure 4.4 shows the Add Formula Window. The prover was created using ANTLR, a parser generating tool that requires a context-free grammar to create a parser. All the rules have a simple design that allows for a fast. Figure 4.2 shows the context-free grammar that ANTLR used in the original prover. 16/34

17 Figure 4.2 The context free grammar for the parser The third method of obtaining a formula is constructing it from the buttons, instead of using the parser. This takes significantly longer to do for long formulas, as the user needs to click on buttons associated with each operator. Figure 4.4 shows all the buttons that are used to create a formula. Regardless of method, once the GUI has a formula it is saved in an array whose contents is outputted onto the Main Window, as seen in Figure /34

18 Figure 4.3 The Main Window of the Tableau Prover After a formula is introduced into the GUI's array, the user can either click the "Prove Selected" or the "Prove All" button. On a single formula the effect is the same. The only difference, as the name suggests, is that, from two or more formulas, "Prove Selected" will prove the conjunction of the selected sub-formulas, while "Prove All" will prove the conjunction of all sub-formulas in the GUI's formula array. Figure 4.4 The Three ways of to Add a Formula 18/34

19 Depending on whether or not the given formula is satisfiable, the output will slightly vary. If the given formula is satisfiable, the Tableau window will output "Yes" in the Satisfiable field and it will show a model for the formula. If the formula is not satisfiable, the Satisfiable field will output "No" and no model will be displayed. Figure 4.5 shows the Tableau Window for a satisfiable formula. Figure 4.5 The Tableau Window of Hanah Anderson's Prover What will be outputted regardless of whether the formula is satisfiable or not is the derivation of the formula and, if the "Print Trace" is clicked, the trace of the derivation. The trace outputs how the derivation was extended with each sub-formula extension and changed when a contradiction was reached. The original prover also has a SPASS Satisfiable section. SPASS is a separate theorem prover developed at the Max Plank Institute for Informatics. The SPASS prover was integrated in Hanah's prover in order to test if the correctness of the artefact. 4.2 Changes in the design The overall design is easy to use and does provide information in a way that can be understood by anyone that would use the prover. While alternative designs might be return the information in an easier to understand form, this design is clear enough when [2] is read. For this reason most of the design will be kept in the extension. Most of the changes in the design will be on the output as now there will be more information to present. The extended prover will not provide a way for multi-modal operators to be introduced with buttons. This is because it would take too much time to introduce such a formula this way. In 19/34

20 the report for the original parser, Hanah has mentioned that buttons were the original way of input and how troublesome they are for long formulas. Because the extended system will have new operators and will also introduce the concept of a C rule, the derivation needs to be extended to show which line is a C rule line. While, according to the congruence closure system, a C Rule is derived from an equality reasoning that two worlds are equal (orientation), implementing that would mean having an equality reasoning line whose extension creates a C rule line. This creates somewhat repetitive information in the derivation, as a C rule can only be attempted from two worlds that are assumed to be equal. To avoid this, a C rule line should be created if two worlds might be equal, thus integrating two lines into one. This line will be derived from the creation of a new world - meaning that there exists at least two worlds to merge - according to the rule of orientation and would expand to the lines it rewrote. Figure 4.6 shows a C rule line, as seen in the formula derivation. Figure 4.6 C rule line in the derivation Since the model presents the conditions for the formula to be true, if a formula is satisfiable, the model needs to be extended to show the C rules that must be applied in order to achieve the solution. This added information also serves to inform the user that some existing relations and valuation are created by the rewrite of a C rule and without certain C rules those relations/valuations would be different. The extended model can be seen in figure 4.7. Figure 4.7 An extended model that includes C rule information The other lines of the derivation need to be extended in order to show which and operators are modal and which are multi-modal as well as show which lines are being changed by the C rules. A relation line is extended with two new sections one or each world, as well as an identifier that for the use of the multi-modal operators. A formula line is extended with one section to show which C rules apply to the line, if any. The multi-modal and operators are called mdia and mbox in order to distinguish themselves from the modal and. 20/34

21 Figure 4.8 The extended derivation lines The parser of the system does not need changes since it works just fine. The only changes to the parser are the multi-modal and operators. They will be parsed in the same way as their modal counterparts. The modal and also required identifiers but they were not used. The multi-modal operators will make use of these incorporated identifiers. The only addition to the parser will be a simple function that reads from a file a list identifiers and frame conditions and creates a map of identifiers to frame conditions for the prover to use. The SPASS prover would require some updating to understand the new and operators. The amount of time to implement everything will now allow for the update of the SPASS prover. As a result the "SPASS Satisfiable" section will be remove so it does not give false results. The extra space will be used on a section to show all the identifiers and the frame conditions they are associated with. This will be a text box that reads from a file that the parser uses as an identifier to propriety map. The format for the mapping will be simple and easy to understand. Figure 4.9 The redesigned Tableau Window 21/34

22 Chapter 5 Implementation 5.1 Multi-modal Operators The multi-modal and operators are proven nearly the same as the normal and with the simple exception that multi-modal operators create and use relations that have identifiers. The parser has to be able to accept both modal and multi-modal operators, therefore, there has to be some difference between the two in the code. For this reason the modal and and the multi-modal ones are treated as different objects, with the multi-modal and having an identifier variable added. Relations are also extended to have an identifier that is meaningless to the modal and, but is very important to the multi-modal and. If the is a modal one, the identifier will have a default value and if the is a multi-modal one, its identifier will also be the identifier of the relation. Figure 5.1 Modal and multi-modal being expanded Like the expansions for modal and multi-modal, the multi-modal will also be expanded mostly the same as the modal. The difference in the case of the operator is that, when the expansion function will look for relations that the modal, the multi-modal will have the added condition that it's identifier must match the identifier of the checked relation. 5.2 Frame Conditions Frame Conditions are used to increase the number of relations between worlds. The original system created one relation for every sub-formula that had to be proven. The extension needs to allow the relations that are created in order to expand operators need to be able to have frame conditions. From these frame conditions, when a new relation is created, more relations between worlds are created, due to the proprieties of the relations (e.g. transitivity). The starting prover needed a function that creates new relations based on the proprieties of existing relations. The function is called whenever a sub-formula has just been expanded. By associating the proprieties with the relation id, it will be easier to allow different identifier's to have different proprieties. All the relations that are used for the application of a property must 22/34

23 have the same identifier and the id must be associated with the property (e.g. The identifier "trans" is used by relations that are transitive). Furthermore, when a new relation is created from frame conditions, the new relation will have the identifier of the relations used to create the new one. The frame conditions function has code for implementing two all the known relation proprieties. The function will only create new relations if the existing ones that are used are transitive and/or Euclidean. The reason for this was that the frame conditions served mainly as a way to test if the existing system could be extended to have relation proprieties and to cause the prover to not terminate so blocking can be tested fully. Figure 5.2 shows the rules for the implemented frame conditions. Figure 5.2 Transitive and Euclidean relations In order to test if the system could cope with having frame conditions for relations, one propriety had to be implemented that would create relations between worlds not directly related otherwise. Euclidean relations are between worlds that otherwise would not be related to each other directly, unlike reflexivity and symmetry. This meant that the working implementation of Euclidean relations would offer some assurance that the other proprieties could be implemented. As the main goal of the project was to create a prover will terminate through the use of blocking, the frame conditions had the purpose of creating a situation in which the prove would not terminate so blocking can be fully tested. One of the simplest example of a formula that may not terminate requires transitivity. Because of this fact transitivity had to be implemented before blocking could be implemented and tested. While the frame conditions function may be called whenever any sub-formula is expanded, and hence a new relation is created, in the case of the modal, there are no frame conditions associated with the default identifier. It is for this reason that the function is only called if a multi-modal is expanded. The function is called right before the sub-formulas of past expanded operators are applied This allows the prover to find if the formula is satisfiable much faster, all while allowing the user to still use one multi-modal instead of the modal one, if he/she desires frame conditions. 5.3 Blocking The congruence closure system will be used to create C rules. The C rules will rewrite the worlds that are being created by any sub-formula expansions. This is done in order to stop 23/34

24 any sub-formula from creating an infinite amount of 's that will prevent the prover form reaching a solution. The C rule will be a pair object that contains two worlds as mentioned in the theory. The tableau will also have a C rule line that is used to show when a rewrite occurs. The prover will have a function that is used whenever a C rule must be expanded. When a C Rule is expanded, the function will mark all the tableau lines that contained the first world of the C rule as inactive. For all lines made inactive by the function, a new line is created that contains the sub-formula of the inactive line, but with the second world of the C rule instead. If the new line has the same world and sub-formula as an already existing line that is being expanded, then expanding the already existing line is sufficient to prove the new line. When the prover encounters an inactive line, it simply ignores it instead of expanding it. This is how infinite expansion is blocked. The blocking function does not use all of the congruence closure rules as they are given in order to provide a simpler model. The Deletion, Orientation and Extension rules are all integrated into the Simplification rule due to the fact that they will usually be used together. Additionally the Deduction, Composition and Compression rules are not used due to the fact that a simple check can ensure that their premises are never reached. Figure 5.3 The Orientation, Deletion, Extension and Simplification rules Where the Composition rule would be used if a C rule attempts a rewrite to a world that has already been rewritten, the system checks if a world has been rewritten before creating a C rule to that world and if yes, a C rule is created to the whatever the world is now called. Similarly, the rewrite of a world is only attempted if the world was just created or the C rule for it was just backtracked from, thus preventing the premise for using the Deduction rule. Finally the Compression rule is not used because the system keeps information on C rules to present in the final model ({c d} means replace all occurrences of world "c" with "d" and have no C rule). 24/34

25 Figure 5.4 The Deduction, Compression and Composition rules Since congruence closure does not dictate which worlds to be merged, this is decided when the C rule is created for a C rule line. For the blocking strategy the system will attempt to do parent merging. I have chosen parent merging instead of root merging because this makes it less likely to cause contradictions. The C rule used to achieve parent merging is created as part of the multi-modal expansion rule as soon as the frame conditions have been used to create all the relations. It is not a part of the modal expansion rule because the modal does not expand frame conditions and hence cannot stop the prover from terminating. 5.4 Backtracking Because with blocking there exists a choice as to which worlds to be merged, and some mergers cause contradictions, when a contradiction appears that can be traced back to a merge, the system can backtrack to the point when the C rule for that merge was created and undo every change that C rule has done. Finding the C rule that caused a contradiction is a simple problem. When a line that offers choices in how to expand it is being expanded (i.e. a disjunction or a C rule), the line number is stored in an array. When a contradiction appears, the system goes through all the lines that offer choices and checks If any of those lines are involved into the contradiction, everything created by expanding that decision line is being reversed and re-expanded in a different way. The C rule has a function for expanding it and a function for reversing what the expansion did. After that, because of unrestricted blocking, the system will try to find if there are any other worlds to which a C rule can be made for the world that could not be rewritten. Unlike the initial merger, which is attempted with the parent, the following rewrite attempts are with any world that was created before the world that is being rewritten, regardless of any relation. If another contradiction is caused by the new C rule, the system backtracks again and rewrites until no contradiction appears or there are no C rules to be created. 25/34

26 5.5 Code changes and Bug Fixes The starting prover was coded to cover modal logic. Because of this certain assumptions were made in the implementation that were not wrong for the original prover but that cause bugs in the extension of the code. For the system to work with the new extensions some changes had to be made to the starting prover in order to keep most of the functionality and only change what was causing the bugs. The original prover worked under the assumption that a relation is a way of showing the creation of a new world. If a world was the second element in a relation, than that world was just created. Under this assumption, when the system would backtrack and delete a relation, it would also delete the second world in that relation from the worlds array. Since the extended system allows for a world to be the second element in more than one relation, this assumption no longer applies. As a result, when a relation is removed as part of backtracking, the world is not removed unless there are no relations that contain that world. Another assumption made when developing the original prover was that it will only make decisions when expanding a disjunction. This does not apply to the extended system because a C rule offers the decision of assuming two worlds are equal. When backtracking, the original system did not check if the decision point to backtrack to was a disjunction or not. While this was not mistake in the original system, the extended system requires such a check in order to know what the alternative decision is. Outside of the bugs caused by assumptions there was one final bug that had to be fixed for the parser. In the original parser, the conversion to negation normal form was being made wrong. When the negation of a conjunction or disjunction had to be simplified, the prover would convert the conjunction to disjunction and vice versa, but would not change the sub-formulas of that conjunction/disjunction to their negation. This meant that every time a negated conjunction/disjunction had to be simplified, the prover would receive the wrong NNF formula. 26/34

27 Chapter 6 Results This chapter will present the extended system in action by providing an example of how the parser finds a model for a multi-modal formula. The formula will be one that would cause the prover to never terminate without blocking. The formula will be ( a) ( a) with the identifier being the same for all operators. For this formula if the multi-modal and use an identifier that is mapped to transitivity, if no blocking was implemented, the would create a new a sub-formula in every world and the a subformula would create a new world for the to use. This would cause the non blocking parser to never terminate. 6.1 Input The extended parser has two ways of imputing a multi-modal formula: as a text by using "Parse Text" and as a file by using "Parse File". Both methods work exactly as they did in the original prover, with the addition that the parser they use can now understand the multi-modal operators. Figure 6.1 shows a screenshot of the two ways a multi-modal formula can be parsed. Figure 6.1 Screenshots of the two ways to parse a formula 27/34

28 6.2 Output Once "Prove All" or "Prove Selected" has been clicked the prover will create the derivation of the given formula. Once the derivation is complete the Tableau Window appears and shows if the formula is satisfiable or not. Since this formula is satisfiable, it will also show a model for it, as seen in Figure 6.2. Figure 6.2 Screenshot of the Tableau Window Model By scrolling on the horizontal side bar the user can also see the final derivation of the formula as well as a list of identifiers and the frame conditions they are associated with (see Figure 6.3). Figure 6.3 Screenshot of Derivation and Frame Conditions 28/34

29 Chapter 7 Testing Testing was performed on both the new functions of the extended prover and on the old ones. The old functionality was tested using the test files provided by Hanah Anderson along with her prover. Performance tests were also executed to check if the added functionality makes the prover slower or faster. 7.1 Unit testing Unit testing was performed on all the classes that have received extended functionality. It served as the main method of testing every extension made until the functions could work together to allow prover testing. Unit testing was also performed on the old system using the already existing test files to ensure that the old prover was not having any parts reach error due to the new functions. Figure 7.1 shows all the test files that were created to test the resulting prover, most of the files being used for unit testing. Figure 7.1 The files for all the tests Unit tests were designed as soon as the design for each extension was vaguely planed. This was done to ensure that each function was being implemented to pass the tests and not vice versa. The unit tests for the SPASS prover were ignored as SPASS is not used in the resulting artefact. 7.2 Blocking testing Blocking had to be tested several times during its development. First was the testing of the parent blocking. The goal was to determine if the prover would now reach termination for all formulas and that the solution was correct. Afterwards, the backtracking from a C rule that caused a contradictions was tested. The goal was to test if upon backtrack, the prover would evaluate each sub-formula in the world it is supposed to. Finally, unrestricted blocking was 29/34

30 tested to determine if the prover is capable of merging worlds that are not directly related to each other. Table 7.1 shows what the structure of the formula was, what were the expected result computed on paper and the output of the prover. The expected outcome consists of valuations and active and failed C rules if formula is satisfiable, output must be "No" otherwise. Test No. What was the test Expected outcome Actual outcome 1 Formula with no contradictions All valuations are in the root world and for As expected that expands infinitely every diamond there is a C rule active 2 Formula with contradictions if root and child world are merged One valuation made in root and another made in child world and a failed C rule for merging child and root world As expected 3 Formula with contradictions if root and any other world are merged that expands infinitely 4 Formula where no child world can be merged with the root but child worlds do not contradict each other if merged 5 Unsatisfiable formula because of a contradiction between a box ad a diamond 6 Disjunction between test 5 and another version of test 2 7 Formula with contradictions if root and certain other worlds are merged that expands infinitely One valuation made in root and another made in child world, C rule for root failed and one C rule active to ensure blocking Some valuations are in root and all child worlds are merged together along with their valuations Output is "No" Prover expands test 2 Merge occurs between any child and its parent if they do not have contradicting valuations. Valuations exist in all worlds that are not merged with their parent as well as in root Table 7.1 Tests performed on all features of blocking 7.3 Prover testing The validity of the extended prover was tested on a file with 102 labelled formulas. Out of the 102 formulas: 96 were labelled "satisfiable" without frame conditions, 2 were labelled "unsatisfiable" and 4 were labelled "unknown". For all formulas labelled "satisfiable" and "unsatisfiable" the prover returned the result matching the label. For the formulas labelled as "unknown" the prover did not reach a conclusion in a reasonable amount of time and was thus terminated. For each formula, the time it took for the prover to reach a conclusion with blocking was compared against the time it took without blocking. Figure 7.2 shows the amount of time each As expected As expected As expected As expected As expected 30/34

31 method of proving has taken. Figure 7.2 does not show all the data as there were two formulas for which the time was above 200 milliseconds. For those formulas the prover has shown to be faster with blocking. These formulas were excluded as the figure would show all the values from 0 to 10 milliseconds on the same line Milliseconds 30 Without Blocking With Blocking Formula No. Figure 7.2 Speed of the prover with and without blocking 31/34

32 Chapter 8 Conclusion 8.1 Reflection on the achievements The goal of this project was to create a working Tableau Based Theorem Prover that incorporates multi-modal operators, frame conditions and blocking. The most desired feature to be implemented was blocking. Blocking was implemented and all its features were fully tested. Multi-modal operators have also been implemented exactly as required and allow the user request a proof both with and without frame conditions by keeping intact the modal and. However, due to time constraints, relations only have two frame conditions implemented. Frame conditions were needed in order to show why blocking is needed and for this purpose the goal was achieved. However, with the other frame conditions implemented the prover would be able to test prove a higher number of formulas. The difficulty in implementing blocking is what limited the number of frame conditions implemented, as there was simply not enough time to implement and test any more frame conditions after blocking was fully tested. On a personal level, I have gained a deeper understanding of how modal logic works, as well as an understanding on how multi-modal logic and blocking work. I also gained experience into how difficult it is to expand someone else's code and use new tools without some introduction to them. I believe this experience has made be grow as a programmer and I am now better equipped to work in industry. 8.2 Future work While the prover is now capable of doing everything that was desired of it at the start of the project, there is still more work that can be done to improve the end product. The extension of the prover was difficult due to insufficient documentation. Not all frame conditions were implemented. And the user interface is only usable by someone that has an understanding about both modal logic and how the prover works. The code for the prover is not very well distributed, as there are some classes with less than fifty lines of code and other classes with over one thousand lines of code. This makes any extensions on the prover very difficult as too much time would be required for code understanding. The code must be restructured and better commented to allow a faster understanding if any other extension is to be made possible. I have made an effort to code my extensions in order to make it easier to understand, but that might not be enough. 32/34

33 The function for implementing frame conditions is easy to understand without needing a deep understanding of the whole system. This and the fact that there are already two frame conditions implemented to serve as examples means that the rest of the frame conditions can be implemented and tested with few difficulties. The user interface is not intuitive and there are no buttons for using multi-modal operators. The button system should either be extended to include the buttons or simplified to only allow the user to use the parser to give a formula. This is something Hanah Anderson has also mentioned in [2]. Some examples into how each operator is called might also be useful (e.g. let user know that "dia" means modal " "). Lastly the output can be more detailed than just a derivation and a model. Figure 2.4 and Figure 2.5 seem more intuitive and allow for an easier understanding of how worlds formulas and relations work together. 33/34

34 References [1] Schmidt, R.A. and Waldmann, U.(2014) 'Tableau with Congruence Closure Notes The Paper', University of Manchester [2] Anderson, H.(2012), 'Tableau Prover with Dynamic Backtracking', University of Manchester [Online] Available at: (Accessed: 27 April 2015) [3] Voronkov, A. (2014), 'Logic and modelling', University of Manchester [Online] Available at: (Accessed: 24 November 2014) [4] Herzig, A.(2008), 'The basic multimodal logic K', [Online] Available at: t=8&ved=0cgqqfjah&url=http%3a%2f%2fwww.irit.fr%2f~andreas.herzig%2fcmodal Logic%2FCh2MultimodalK.pdf&ei=g7E-VevEN5D3aovTgPgE&usg=AFQjCNGOJFbdAsLfUOXt_FH9pC0qs1ZmQ&bvm=bv ,d.d2s (Accessed: 22 November 2014) 34/34