Computer Science Department

CS534 - Artificial Intelligence

Wed 6:00-9:00 pm.

Prof. David C. Brown, Fuller Labs 131, (508) 831-5618, dcb@cs.wpi.edu


PROJECT 1 - A Rule Interpreter

Write a simple rule interpreter and demonstrate its capabilities for a simple situation-recognition problem.

Each rule should be of the form Situation recognized leads to Action executed causing change in situation or Situation-Action for short. A rule executor, or Inference Engine, (IE) acting on a set of rules, will incrementally transform a description of some "initial" situation into a description of some "terminal" situation, by using one rule at a time. Each rule makes a small change in the situation.

The initial situation probably represents a problem to be solved, while the terminal situation is probably some form of answer. The current situation description is held in a Working Memory (WM). The description in the WM consists of a set of simple descriptions, or facts.

The left hand side (LHS), or "situation recognition" side of a rule can be expressed as a boolean expression of arbitrary predicates. These predicates must be pre-defined. The right hand side (RHS), or "action" side can be any sequence of actions. These actions too must be pre-defined. The actions act on the working memory. By pre-defined we mean that they are provided in files that are read in by the system (i.e., by the IE), along with the rules, prior to any rule execution, and are not "built into" the IE. This makes the IE independent of any particular domain.

In the example below the action form (A v) means "set the value of the attribute A to v". So "(Plant-is Yes)" means "set the value of the attribute Plant to Yes"; i.e., It is a plant. The "Green?" predicate shown below is a short form for "Does the attribute Color have the value Green?". Similar interpretations apply for other predicates. These forms were chosen for improved readability.

Here is a sample set of rules. Yours do not have to follow this form exactly.

	Green? AND NOT Heavy?  		--->  (Type-is Grape) 
	Round? AND (Red? OR Green?)	--->  (Type-is Apple) 
	Red?     			--->  (Type-is Tomato) 
	Tomato?  			--->  (Plant-is Yes) (Height-is Short) 
	NOT Ripe?  			--->  (Color-is Green) 
	CanCarry?  			--->  (Heavy-is No)

For the demonstration of your system you should use a simple working memory consisting of a list, or record, of attributes and values.

For example:

	Type		:  --       
	Plant		:  --       
	Vegetable	:  --       
	Fruit		:  --       
	Ripe 		:  No       
	Color		:  --       
	Shape		:  Round       
	Heavy		:  --       
	Height		:  --       
	Carry 		:  Yes       
	Weight		:  -- 

To extend the use of the defined predicates you will need explicit variable binding. Make both the fetch and bind to a variable, and the test to see if an attribute has a value (i.e., Value?), separate functions (disguised as predicates). As this can be difficult, depending on how you choose to implement it, and in what language, this will be for extra credit (10%). Here is an example:

	(Bind Weight y) AND (> y 10)  		--->  (Heavy-is Yes) 
	(Value? Vegetable)   			--->  (Print "It's not a fruit!") 
	(Bind Type z) AND (Equal? z Tomato) 	--->  (Fruit-is Yes) 
	(Bind Height p)  			--->  (Width-is p)

The control of rule selection and execution works as follows. All of the rules are examined to see if one or more matches the situation. If only one matches then the action (RHS) of that rule is executed. If more than one rule matches, the one that is most specific is used. Specificity is up to you to define, but it probably has something to do with the length of the LHS. If there are two or more rules with the same specificity then the one chosen is the earlier in the rule list. You will have to worry about the same rule firing again in an unchanged situation, and when to stop the system.

Include the saving of predicate values in the interpreter during one situation matching pass through the rules. For example, if "Green?" appears in the first five rules it makes no sense to fetch and test the value of the color attribute five times. However, in some implementations this mechanism saves no time -- point this out and explain what you have (not) done.

Input the rules, the definitions of all predicates and actions, and the initial state of the working memory -- all from separate files. The program handles input, output, rule selection and rule execution. For the due date, see the Schedule. In some programming languages it will be difficult to arrange for new predicates and actions to be input. If you think this is a problem, then discuss it with me.

The problem that you are to solve as a demonstration is up to you. A set of about 10 rules will be adequate. If the problem doesn't show the capabilities of your system fully then also include an example, not necessarily meaningful, that does. Note that you will be using this system in the final project, and, as a consequence, you should make every effort to program so that that will be convenient. Also note that THIS handout describes the project requirements, and a solution that looks like one in any AI or programming text is not acceptable.

dcb@cs.wpi.edu; Wed Aug 27 19:10:29 EDT 2003