Computer Science Department

CS4341 ❏ Artificial Intelligence ❏ B07

Mon, Tue, Thu, Fri - 1:00 - AK 233
Prof. David C. Brown, Fuller Lab 131, (508) 831-5618, dcb at cs.wpi.edu

Version: Mon Oct 29 22:08:04 EDT 2007

PROJECT 1 - A Rule Interpreter & an Intelligent System

Due Date

This project is due on Tuesday 13th November 2007


The purpose of this project is to:

  • introduce you to a powerful, general-purpose reasoning tool;
  • to have you use it to implement an intelligent task in the landscape domain;
  • to illustrate a simple LISP/Scheme-based language;
  • to introduce you to a basic set of types of reasoning tasks; and
  • to provide experience with "knowledge acquisition".

Part 1 - A Rule Interpreter

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

A Rule Interpreter (RI) is a kind of problem solver that uses problem-solving knowledge in the form of rules. A rule says what to do in a particular situation. The rule interpreter inspects these rules and uses them to solve a problem. The problem's initial conditions are requirements, a starting state, or symptoms, for example. That starting situation is given to the rule interpreter as a set of facts. The rules cause the rule interpreter to react to the facts to produce new facts, eventually leading to a set of facts that form an answer. We refer to the current set of facts as the state of the problem, or the "situation".

Each rule should be of the form "Situation recognized leads to Action executed, causing change in situation" or Situation-Action for short.

The key piece of the RI is a rule executor, or Inference Engine (IE), that acts on a set of rules. Using one rule at a time it will incrementally transform a description of some "initial" situation into a description of some "terminal" situation. The initial situation represents a problem to be solved, while the terminal situation is some form of answer.

The situation description is held in a Working Memory (WM). The description in the WM consists of a set of facts. These facts are simple descriptions of aspects of the problem or solution (see below for details).

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 (i.e., pre-loaded for the RI to use). 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 the predicate and action functions are given as input to the system, 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, as other predicate and action definitions could be used.

In the example below the action form (A-is 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" in the WM; 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. Other forms are possible.

Here is a sample set of rules. You do not have to use this form exactly, but you must follow it very closely.

    (IF ((Green?) AND (NOT (Heavy?))) THEN ((Type-is Grape)) )

    (IF ((Round?) AND ((Red?) OR (Green?))) THEN ((Type-is Apple)) )

    (IF (Red?) THEN ((Type-is Tomato)) )

    (IF (Tomato?) THEN ((Plant-is Yes) (Height-is Short)) )

    (IF (NOT (Ripe?)) THEN ((Color-is Green)) )

    (IF (CanCarry?) THEN ((Heavy-is No)) )

    (IF (TypeHasValue?) THEN ((Stop)) )

For the required demonstration of your system recognizing a situation, you should use a simple working memory consisting of a list of attributes and values. The size of the WM is fixed when the RI reads it. Only some of the values will be known at that time. Actions add values to the WM.

The use of "nil" below indicates that no value is known. Use another value to indicate "False" or "No". You can choose which values you want to use.

For example:

    (Type nil )
    (Plant nil )
    (Vegetable nil )
    (Fruit nil )
    (Ripe No )
    (Color nil )
    (Shape Round )
    (Heavy nil )
    (Height nil )
    (Carry Yes )
    (Weight 2 )

The control of rule selection and rule execution works as follows. All of the available rules are examined by the IE to see if one or more matches the situation described by the WM. A rule matches if its LHS evaluates to True. Predicates evaluate to True or to False by testing entries in the WM. If only one rule matches then the actions in the action list (RHS) of that rule are executed in sequence. This will change the WM.

If more than one rule matches, then that set of matching rules is known as the "Conflict Set". The rule in the set that is most specific is the rule 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 one earlier in the rule list. The idea is that more specific rules are more precise and should be favored over those which are less precise.

Matched rules are called "triggered" rules. The one chosen to be used is "fired".

For this RI, allow each rule to fire only once, by removing it from the current list of available rules after it has been used (i.e., after its action list has been used). After a rule fires, and it has been removed from the list, the IE cycles back to start again by examining all the available rules to see which match.

The system stops when no more rules match the current WM, when all rules have been used, or when a Stop action is executed. Stop is a predefined, domain-independent, interpreter-recognized action. This forces the IE to stop immediately.

Input the definitions of all predicates, definitions of all actions, the rules, and the initial state of the working memory: each from separate files. The RI program handles input, output, rule selection and rule execution. Note that the RI needs to produce appropriate output in demonstration mode so that we can see that it is working.

In some programming languages it is very be difficult to arrange for new predicates and actions to be input. If you think this is a problem, then discuss it with me. LISP or Scheme make this quite easy. Java and the Cs, for example, do not. It must be possible to define and use arbitrary predicate and action functions, so that the RI can work with different domains and can do different kind of problem-solving without needing to be changed. No rules, predicates, actions (apart from Stop) or WMs may be built into the RI.

Note that the rules given in this project do not include variables, so there is no binding to keep track of. You are not expected to implement the RETE approach that Winston describes.

Rule Interpreter Testing Demonstration

The situation recognition test problem(s) that you use as a demonstration is up to you. A set of about 10 rules will be adequate. To show the capabilities of your system fully include several different runs. Think of this as a test set and not a real example of problem solving: that comes next!

Please note that THIS problem specification describes the project requirements, and a solution that looks like one online or in any AI text is not acceptable.


For the due date, see the Schedule. Projects must be completed by the start of class on the due date.

Make sure that your name is associated with all items submitted.

You must submit for Part 1:

  • On paper and via web turnin:
    • Brief, clear documentation that describes the design of your RI, including the overall architecture, any special algorithms used, and any special data structures used.
    • A description of how you've handled rule selection from the conflict set.
    • A description of your rule language.
  • Via web turnin only:
    • All the test cases in your demonstration with the corresponding output that shows that the RI is functioning correctly.
    • All the code (which must be well commented).

How to submit:

Part 2 - An Intelligent System


The task is to write an intelligent system (IS), using rules and the RI, to do some basic intelligent task in the landscape domain. Sample tasks might be Design or Diagnosis for example. The domain is the situation in the landscape (e.g., vehicles and obstacles). So, some domain/task combinations might be landscape Design (e.g., designing and placing obstacles to satisfy some requirements), or landscape Diagnosis (e.g., hypothesizing the existence of a "problem" in the landscape).

Problem Characteristics:

The problem must:

  • be solved using only the Rule Interpreter (RI) from Part 1;
  • be challenging enough so that it cannot be done in a single step;
      {i.e., reasoning requires many rules to be used, with intermediate results, in order to produce a solution}
  • require some specialized knowledge to solve;
  • be able to be done naturally using forward chaining;
  • allow its statement and solution to be expressed in the attribute/value format of the RI's Working Memory;
  • not require any, or much, calculation;
  • not require any human intervention or additional input;
  • not require backtracking (i.e., retracting values already decided) to solve;
  • be challenging enough that class members would agree that solving it requires intelligence, not just memory.

Sample Tasks:

In order to build a rule-based system to implement the intelligent task you select, you first need to define the task clearly. Do that in terms of the inputs it requires, the knowledge it needs, the output it produces, and a characterization of the transformations it makes on the input.

As a way to help you get started, here below are some basic tasks that might be candidates for your IS. Your system must be an example of one of these types of tasks.

    Configuration selects and arranges components from a predefined set in order to satisfy some requirements. Typically, each component has a restricted set of possible connections.

      {e.g., producing a description of a table appropriate for small, light loads that has a base, a top, and one central leg}

    Criticism compares an item against a standard, or some preferences, and points out the ways in which it is lacking.

      {e.g., pointing out that something very heavy with lots of sharp edges will be very hard for people to lift and move around}

    Diagnosis by Classification can be used to categorize a given state as a certain type of known problem in order to decide what sort of treatment might be used.

      {e.g., deciding that someone with blue toenails and a cough has Fitzwilliam's disease, so that a treatment might then be selected}

    Evaluation uses the results of analysis, or some specific aspects of the item, to provide an estimate of its quality or the degree to which it meets some goals.

      {e.g., deciding that a 2 foot thick table top made of marble is a poor quality solution}

    Parametric Design produces values for attributes, such as color or length, by calculation, or by simple selection.

      {e.g., deciding the material, paint color, and dimensions of a table top.}


Note that forward-chaining is typically used when you want to drive the reasoning from the data towards the solution. Backward-chaining is typically used when you have a hypothesized result that you want to show. Diagnosis is often associated with backward reasoning, and design with forward. It isn't really quite that simple. Diagnosis can be done in a forward fashion by proposing hypotheses from the data, for example.

If you need to decompose the problem into pieces, or the reasoning into phases, then leave "flags" in the WM that say what subgoal is currently being tackled. So, for example, an entry in the WM might be (phase 2), and a rule might say something like (IF ((SecondPhase?) AND ...) THEN ( ... )).

You will need to develop a set of predicates and a set of actions that can be used in rules to express the knowledge that can be used to solve the problem. Feel free to add special actions if you need them, that print for example. All rule interaction must only be through values set in the WM. Note that some of your predicates will need to access the landscape.

Intelligent System Demonstration:

The details of the landscape domain, and the intelligent task that you are to implement and demonstrate, is up to you. A set of about 30-50 rules will be adequate. To fully show the capabilities of your IS include a variety of runs with different initial situations. For some of the key runs a clear, self-explanatory "demonstration" must be provided, not just the initial input and the answer.

Note that THIS page describes the project requirements, and a solution that looks like one online or in any AI text is not acceptable.

Submit Part 2:

For the due date, see the Schedule. Projects must be completed by the start of class on the due date.

Given how much material is being submitted for this whole project, you must make sure that your name is associated with all items submitted.

You must submit for Part 2:

  • On paper and via web turnin:
    • Complete descriptions of your problem and your domain.
    • An explanation of how you've used forward-chaining for this problem.
    • Brief, clear documentation that describes the design of your intelligent system, including the structure of the reasoning done (e.g., what sort of intermediate results are obtained, and how they are used).

  • Via web turnin only:
    • All the test cases that are intended to show that the IS is functioning correctly. These should be commented to explain what they are supposed to mean/show.
    • The output from the IS test/demonstration runs. These should not be annotated as they should be self-explanatory.
    • A listing of all the rules, predicates, and actions.

How to submit:

Please note:

  1. Clearly label all printed work with your name.
  2. Clearly label each file with a helpful name.
  3. ZIP your entire project directory. Make sure it only contains the files to be submitted. Use "zip" and not some other compression tool.
  4. Name the zip file as your user name + "-proj1.zip"   For example, "jefferson-proj1.zip"
  5. Submit the zipped project using web turnin.
  6. The project's turnin assignment name is "project1".
Please let us know if you still have problems.