CS322 Fall 1997
Assignment 9 Solution

Due: 1:30pm, Friday 14 November 1997.

Question 1

In this question you will write a meta-interpreter for parameterized logic programs. These are logic programs that can use constants in arithmetic expressions. The values for the constants are given as part of the input to the meta-interpreter.

Assume that an environment is a list of terms of the form val(Parm,Val), where Val is the value associated with parameter Parm. You can assume that each parameter only appears once in an environment. An example environment is [val(a,7),val(b,5)].

In cilog, you can use <= as the base-level implication and & as the base-level conjunction. You may need to get a new version of cilog that has <= defined as an infix operator and with number as a built-in predicate. There is a new version in ~cs322/cilog. An example meta-interpreter is given in prove.pl.

  1. Write a predicate lookup(Parm,Val,Env) that is true if parameter Parm has value Val in environment Env. You can use member (defined in class and in the text).
  2. Write a predicate eval(Exp,Val,Env) that is true if parameterized arithmetic expression Exp evaluates to number Val in environment Env. An expression is either Assume that the operators have their usual meaning, that numbers evaluate to themselves, and that parameters evaluate to their value in the environment. You can use the cilog predicates N is E that is true if (unparameterized) expression E evaluates to number N, and number(E) that is true if E is a number.
  3. Write a predicate pprove(G,Env) that is true if goal G is a logical consequence of the base-level KB, where parameters are interpreted in environment Env. An example interaction with cilog is:
    cilog: tell f(X,Y) <= Y is 2*a+b*X.
    cilog: ask pprove(f(3,Z),[val(a,7),val(b,5)]).
    Answer: pprove(f(3,29),[val(a,7),val(b,5)]).
     Runtime since last report: 20 ms.
      [ok,more,how,help]: ok.
    cilog:  ask pprove(f(3,Z),[val(a,5),val(b,7)]).
    Answer: pprove(f(3,31),[val(a,5),val(b,7)]).
     Runtime since last report: 10 ms.
      [ok,more,how,help]: ok.
    cilog: tell dsp(X,Y) <= Z is X*X*a & Y is Z*Z*b.
    cilog: ask pprove(dsp(3,Z),[val(a,7),val(b,5)]).
    Answer: pprove(dsp(3,19845),[val(a,7),val(b,5)]).
     Runtime since last report: 20 ms.
      [ok,more,how,help]: ok.
    cilog: ask pprove(dsp(3,Z),[val(a,5),val(b,7)]). 
    Answer: pprove(dsp(3,14175),[val(a,5),val(b,7)]).
     Runtime since last report: 10 ms.
      [ok,more,how,help]: ok.
    
Solution

Question 2

Cilog has askables that are atoms that are asked on the user, and assumables that are collected in an answer (i.e., they are delayed).

Imagine you are axiomatizing the wiring in your home and you you have an axiomatization similar to elect.pl given in the text (section 3.2) and available on the web. You are axiomatizing the domain for a new tenant who is going to sublet your home. They need it to determine what may be going wrong with the wiring.

There are some predicates that you will know the definitions for, some that the tenant will know, and some that neither will know. Divide the predicates into these three categories, and suggest what predicates should be made askable, and which should be assumable. Show what the resulting interaction will look like under your division.

Solution

The aim of this question was to get you to think about the roles.

In general, you would expect that you (as the domain expert) will know the rules about connections, what is connected to what, but not what is OK, nor what positions the switch is in. The tenant (as the user) will know about the positions of the switch, but not about the connections. Neither will know about whether the lights are OK.

What I would have liked you to have noticed (but not necessarily to have the tools to solve) is that the user will be able to observe whether the lights are lit or not, but will now know the reason for them being lit (i.e., the rules that imply why they are lit). But that that the domain expert will know about the rules, but not necessarily about whether the light is actually lit. This was meant to provide a motivation for consistency-based diagnosis.

Here is an axiomatization of the electrical domain with askables and assumables that can return conflicts. Here is a trace of this axiomatization for finding conflicts:

CILOG Version 0.11. Copyright 1997, David Poole.
CILOG comes with absolutely no warranty.
All inputs end with a period. Type ``help.'' for help.
cilog: load 'elect_delay.pl'.
CILOG theory elect_delay.pl loaded.
cilog: ask false.
Is up(s2) true? [yes,no,unknown,why,help]: yes.
Is up(s1) true? [yes,no,unknown,why,help]: yes.
Is dark(l1) true? [yes,no,unknown,why,help]: yes.
Answer: false.
Assuming: [ok(l1),ok(s2),ok(s1),ok(cb1)].
 Runtime since last report: 30 ms.
  [more,ok,how,help]: more.
Is down(s2) true? [yes,no,unknown,why,help]: no.
Is up(s3) true? [yes,no,unknown,why,help]: yes.
Is dark(l2) true? [yes,no,unknown,why,help]: yes.
Answer: false.
Assuming: [ok(l2),ok(s3),ok(cb1)].
 Runtime since last report: 20 ms.
  [more,ok,how,help]: more.
No more answers.
 Runtime since last report: 10 ms.
cilog:

Question 3

How much time did you spend on each question? Was it reasonable? What did you learn?