next up previous contents
Next: Satisfy Once Only Up: Some Practical Problems Previous: Some Practical Problems


We have outlined the use of test --- process to do case analysis but it was necessary to have one clause for each case. If we have a goal which can be satisfied via two different clauses then, on redoing, the same goal may generate a different solution.

In reality, this situation can arise quite often --- i.e. the tests we do on the input do not divide the input into non-overlapping classes. Essentially, we have two problems. We often want to make sure that only one clause is legitimate ---once it has been determined that the input passes some test. We think of this as a statement of commitment to the solution(s) derived through `processing' the input.

 test_process( Info,X,Y):-

test( Info,X),


process( Info,X,Y).

When we backtrack and try to find another way of satisfying some program that makes use of the test --- process schema then we first try to find another way of satisfying the process part. If that fails, then we try to resatisfy the test part. We do not want this to happen.

Then, assuming that we cannot resatisfy the test part, we try to resatisfy the goal making use of this program by trying different clauses.

Therefore there are two senses in which we may want to be `committed': we want to commit to using a single clause and we want to commit to the result of a test ---we do not want to run the risk that the test can be successful (with the same input) twice.

Paul Brna
Mon May 24 20:14:48 BST 1999