Esquemes d’acció logicomatemàtics, l'adquisició del número

The next strategy that will be presented tries to handle the memory manage-ment better than the previous ones. The last two strategies, which are a great deal better than the first, have a weakness that must be overcome to have an efficient algorithm. They do not shut down as soon as an un-connected path has been located, the next strategy does, it will once again be an extension of the last strategy presented. The worst case scenario that can be presented to the last strategies is a matrix without any connections at all, which should be the easiest formulas to investigate. This is because a matrix without any connections will only be able to use the ’extendPath rule, which generates all the paths through the matrix. Now we have to store an exponentially growing number of notvalid elements in our SearchStateList and after all the paths have been evaluated the expression can be simplified. The next strategy will terminate as soon as it hits an un-connected path through the matrix.

metaPush(M, metaRest (M, extrTerm ( metaXapply (M, ACTIVE,

’ negLitInMatrix , none , 0 , unbounded , 0) ) )

metaPush(M, metaRest (M, extrTerm ( metaXapply (M, ACTIVE,

’ extendPath , none , 0 , unbounded , 0) ) ) , STACK) )

e l s e ’ v a l i d . ValidNotValid f i f i f i f i f i .

This function takes three arguments, the last argument holds a stack of not yet investigated SearchState elements in a meta represented SearchStateList, the first argument is our active SearchState element. The idea is to abandon the search as soon as possible. Every SearchState element represents one or more paths through the matrix, depending on whether or not some pruning has been done. If one of these represent an un-connected path, we can call the search off. So in this function we gather new elements produced by the rewrite rules that split our SearchState element on the stack, which is the third argument for this function. Then we continue to investigate the first SearchState element until we have decided whether this element represents connected or un-connected paths. This function also introduces some other functions:

• metaPush

• metaPop

• metaPopped

These three functions will be used to perform the usual stack operations on our meta represented stack. The last function is needed since we store structures differently than in imperative programming languages, when we construct rewrite theories in Maude. The function metaPopped returns the rest of the stack after an element has been popped off, in other languages we usually have a pointer to the stack. When an element is popped off the stack the remaining stack is the remaining stack, but this becomes a bit different here since a function returning a popped off element “destroys” the stack, (we have no pointer to the remains of it). The other two functions has the expected meaning, metaPop returns the elements that gets popped off the stack, and metaPush pushes an element onto the stack.

I’ll try to give a brief illustration of what happens when this strategy controls the execution. This time we start out with a matrix which has no connections at all:

All the strategies start off by placing the matrix (formula) that is to be investigated into the remaining matrix of a SearchState element. This is the result:

< none ; nix ; [[p, q, - r], [s, t], [a, b], [- g, q]] >

Then the SearchState element is initialized, which means we select a clause from the remaining matrix, (now equal to the matrix we want to investig-ate), and make it our first active clause. Say for instance that the clause [p, q, - r] is selected by the init rule. This will be the resulting term:

< none ; [p, q, - r] ; [[s, t], [a, b], [- g, q]] >

Recall that the deductive rules negLitInPath and negLitInMatrix locate connections and prune the search space. This matrix has no connections which means that these two deductive rules will always fail, and the only deductive rule that can be applied is the extendPath rule. After the rule extendPath has been applied to our SearchState element it will look like this:

< p ; [s, t] ; [[a, b], [- g, q]] >

< none ; [q, - r] ; [[s, t], [a, b], [- g, q]] >

When strategy4 controls the execution the first of the two SearchState elements will be investigated further, while the second one will be pushed onto the stack of not yet investigated SearchState elements. Since the only rule that can be applied still is extendPath, this will be the resulting terms after the second recursive call has been made to the function strategy4.

1: < p, s ; [a, b] ; [[- g, q]] >

2: < p ; [t] ; [[a, b], [- g, q]] >

3: < none ; [q, - r] ; [[s, t], [a, b], [- g, q]] >

The ACTIVE SearchState element is no. 1 and the stack consists of 2 and 3.

SearchState element no. 2 was generated when the rewrite rule extendPath was applied to the term:

< p ; [s, t] ; [[a, b], [- g, q]] >

Which was our ACTIVE SearchState element when the recursive call was made to the function strategy4. Now we have a stack of two SearchState elements and one ACTIVE SearchState element.

1: < p, s ; [a, b] ; [[- g, q]] > = ACTIVE 2: < p ; [t] ; [[a, b], [- g, q]] > = STACK

3: < none ; [q, - r] ; [[s, t], [a, b], [- g, q]] > = STACK The function strategy4 is called once again and the only rule we can apply is still extendPath which leads to this situation:

1: < p, s, a ; [- g, q] ; [none] >

2: < p, s ; [b] ; [[- g, q]] >

3: < p ; [t] ; [[a, b], [- g, q]] >

4: < none ; [q, - r] ; [[s, t], [a, b], [- g, q]] >

The last three elements make up the stack, and the first element is our ACTIVE SearchState element. The next recursive call to the function strategy4 will discover that the ACTIVE SearchState element represents a countermodel and the whole proof search is shut down. There is no need to investigate the other elements on the stack further since we already have located an un-connected path (or two in this example). Now we will take a look at the code which controls the strategy just presented. Notice that the stack of not yet investigated elements are only popped off and examined when our ACTIVE SearchState element is connected.

The first if-test in this function is the same as in all the other functions, it tests the active SearchState element for connections between its active path and its active clause, if such a connection is established, this rule is applied.

The next if-test will call the whole search off if the active SearchState element now being investigated is un-connected. Then the recursion stops here:

if (simplify(M, ACTIVE) == ’notvalid.ValidNotValid) then ’notvalid.ValidNotValid

There is no need to investigate the rest of the paths since we already know that this formula is not valid, so the whole search is called off. The next if-test:

if(simplify(M, ACTIVE) == ’valid.ValidNotValid) then

strategy4(M, metaPop(M, STACK), metaPopped(M, STACK))

calls the function recursively with the next SearchState element on the stack, since the previous one lead to connected paths we can continue. The last two if-tests apply rules that split the SearchState element into two new SearchState elements. This situation is now handled by inserting one of these elements onto the stack, and letting the other one become the new active SearchState element.

if

(metaXapply(M, ACTIVE, ’negLitInMatrix, none, 0, unbounded, 0)

=/= failure) then

strategy4(M, metaFirst(M, extrTerm(metaXapply(M, ACTIVE,

’negLitInMatrix, none, 0, unbounded, 0))),

metaPush(M, metaRest(M, extrTerm(metaXapply(M, ACTIVE,

’negLitInMatrix, none, 0, unbounded, 0))) , STACK))

Once again the code can look a bit cryptic, but the idea is hopefully clear.

We push one of the newly generated SearchState elements onto a stack, and finish investigating our active SearchState element until it either leads to connected paths, when we move on with the next element on the stack, or in the case of un-connected paths we shut the whole procedure down. The next if-test is the same except for the ’negLitInMatrix which is replaced by

’extendPath. If all the tests above fail, we have finished without locating un-connected paths, and our matrix represents a valid formula.

else ’valid.ValidNotValid

The complete program can be found in the appendix. I hope that the code is not as cryptic anymore now that some comments about it has been presented.

In the next section these strategies will be tested on a set of formulas to see how the different strategies work.