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.
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.
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.
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: