proofcert / checkers Goto Github PK

Should change modlab and modtab to support multiple indices in the some rule:
everytime we apply some with the decide index, we take the first index from the list and return the list without the head.

create modtab for reflexivity

once Marco is finished with trans/symm add modtab with their support

Leaving out information from the certificate by replacing concrete data with variables.
This works on some holes but fails if we try to replace the whole proof tree with a variable. Try to understand what is the reason for the failure.

We remove modal information from the tree and put it in a separate data structure. Data in the data structure can be mapped to tree nodes. But we can also replace them by variables and then allow the search to decide which boxes and diamonds on which tree node.

This should also lead, hopefully, to the case we omit the tree completely and give only the essential information of the relationship between boxes and diamonds.

The problem:

Currently, we encode from modal into FOL the formula of the certificate and then we use several layers of FPCs in order to translate between the layers.

Marco would like to have concrete kernels for each layer and have a clean translation between evidence in one into the next kernel.

So we use the FPC to generate an output evidence which will be fed to the next FPC in the chain.

This will impose having different kernels for each layer. I.e. on the LMFos layer, there is no decide rule!

Using ELPI in the gandalf2017 branch, when running:
./prover-elpi.sh modtab-min-1

we get the following attached files
min.txt
max.txt

The problem is that in max.txt we store lind (lind eind) and decide on it
In min.txt we store lind (lind X) but we never decide on something of the form lind (lind _) instead, we keep trying the same ones over and over again:

+++ dec inCtxt (lind (rind (lind X0))) (p (q1 x5))
+++ dec inCtxt relind (n (rel zero x5))
+++ dec inCtxt (rind (lind X0)) (d+ (all x6 \ n (rel zero x6) !-! p (q1 x6)))

Try and compare the two. There are some places where unification does not work.

Given a non-terminating process on some certificate, if we replace some terms in the certificate with variables, we get failure. How can it be?! There should be more options now! The only answer I can think of now is that more abstraction causes the unification to fail.

See wiki about general idea.

Marco, I have a question. I figured out how to deal with the box/diamond idea but what are the H and F that we need to give to the diamonds? to the box?

finish modtab-full-reflx by adding decide tree
add transitivity and symmetry to modlab
wait for Tomer to add support for exists on several indices at once

Right now, we wrap a certificate of a deeper layer in an upper certificate. We can abstract it by using default values to initialize another certificate in the later. I.e. LMFos layer will get an LMFos only certificate and generate the wrapping to use LMF*.

LMF* is a sequent calculus for general modal logics. Below we specify the requirements:
a) Proof evidence (is used for checking)
b) Proof state (used by the checker to manage it state)
c) Experts (fpc definitions)

For the systems:

1. LMFsf

2. LMF

3. LMF*

4. LMFsf - for single focus, was targeted by our previous version of checkers (see branch gandalf2016).
   LMFsf could target proofs from tableaux and other modal theorem provers.
   a) The proof evidence consisted of a triple A B C where:
   A) is the label of the formula we need to process.
   B) is an optional value given when the formula is a literal or a diamond to correlate them to complimentary literal or to the associated box.
   C) is the children of the formula (inductive definition of evidence)
   b) The proof state contains a list of computed indices (for storage) and an association between the indices of boxes and the corresponding concrete eigenvariables.
   c) Decide is deciding according to the index in the current node of the tree. Store uses the list in the state for choosing the right index for the formula. All (box) creates an association in the state and exists (dia) validates against this association using the optional argument in the certificate. All rules are setting the list in the state to contain one (unary) or two (binary) indices used for store. Literals are checked against their complementary in the context using again the optional argument in the certificate.

5. LMF allows multi focusing over LMFsf.
   a) We add to the triple also a unique multi focusing index (MFI). This index groups together formulas which we are focusing over. This value is optional.
   (b) and (c) do not change, i.e. we actually ignore this index in the LMF case.

• Maybe we might be able to come up with a general enough restriction on LMF based on MFI. @emmevolpe: yes, it would be nice.

3. LMF* applies restrictions to LMF in order to restrict the search space, based on additional info in the certificate.
   a) Each node will contain information on how to change the H value (see b) and on how to set the (optional) future of the formula. This future consists of one world currently (enough for K).
   b) The state contains H which is a set of the allowed current world of formulas which we can focus on
   c) Based on LMF, in addition: Decide changes to ensure that the present of the formula to focus on is within H. It also uses the supplied future in the certificate in order to apply it as the future of the focused formula. Exists (dia) ensures that the future world is the future component in the label of the focused formula

• Note that we have a mechanism to allow deciding many times on the same formula occurrence in the theorem by using the bind component of an index. This component allows us to distinct deciding on formulas which are within the scope of different diamonds.
  @emmevolpe: I would say: at the moment we assume that we decide more than once only on diamond formulas (possibly because we want to relate them to different boxes). This means we can just use a mapping (index, label) in the proof state.

1. In decide, H contains worlds, right? So I need to compare the value in the map, assigned for the index, to see if it is allowed.

2. Are all worlds indices? The map is initialized in this way. If this is the case, we need to change A to index in all our code (also in the modal_encoding file)

3. It seems there is a problem with init as there are infinitely many inits at the end. What should I change?

In a754baf, some of the paramodulation logic was reportedly moved to the E prover module, whereupon param1 no longer succeeds. One possible way to fix this without apparent side effects is to uncomment the removed decide_ke clauses in paramodulation.mod. Is modularity, with the E certification code or otherwise, at risk?

Hi Marco,

I have finished the lmf-single and multi focused versions.

The singlefoc version seems to work fine but not so the multifoc.

The reason is as we discussed - the special case of store on line 21 in lmf-singlefoc.mod.

As long as the lower level - singlefoc - generates new nodes, we cannot abstract over it.

Can you think how to write this special case without adding new nodes? This is the only problem as far as I can see with our design.

To use the current branch I am working on:

git checkout delay-fix
./prover.sh ftab1 (works)
./prover.sh ftab1-mf (exactly the same but trying to use the multifoc fpc - does not work)

I believe that if you fix this problem in singlefoc.mod, then both will run properly.

The store I am expecting does not add or remove nodes to the tree...