WORCESTER POLYTECHNIC INSTITUTE CS4341 ❏ Artificial IntelligenceVersion: Thu Mar 14 19:00:46 EDT 2013 PROJECT 1 - A Rule Interpreter & an Intelligent SystemDue DateThis project is due on Fri 29 March PurposeThe purpose of this project is to:
Part 1 - A Rule InterpreterWrite 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 might be requirements, a starting state, or symptoms, for example. That starting situation is given to the rule interpreter as a set of facts. The rule interpreter follows the rules 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 textbook also refers to them as "condition-action" rules. They're also called "if-then" rules. An example of a rule is:
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). In textbook terms it is a "factored" representation: effectively a vector of attribute values. For this problem 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 simple 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. The "TypeHasValue?" predicate tests to see if the attribute Type has been given a value. 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)) ) Note that (Stop) is special built-in action that causes the IE to 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, usually 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 still 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, and how. In some programming languages it is very be difficult to arrange for new predicates and actions to be input at run time. 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 some textbooks describe. Note that this system uses "forward chaining": reasoning from situations forwards to new situations. Rule Interpreter Testing DemonstrationThe situation recognition test problems that you use as a demonstration are 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. SubmitFor 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:
How to submit:
Part 2 - An Intelligent System
Overview:The task is to write an intelligent system (IS), using rules and the RI, to do some basic intelligent task in the landscape domain that was developed in project 0. Sample tasks might be Design or Diagnosis for example. The domain is the landscape with elevations, tolls, 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:
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. i.e., the details that the textbook describes as being needed to set up a problem-solving agent. 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. Note that the examples of each task, given in small print, are examples from other domains. Configuration selects and arranges components from a predefined set in order to satisfy some requirements. Each component has a restricted set of possible connections.
Criticism compares an item against a standard, or some preferences, and points out the ways in which it is lacking.
Diagnosis by Classification can be used to categorize a given state as a type of known problem in order to be able to decide what sort of treatment might be used.
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.
Parametric Design produces values for attributes, such as color or length, by calculation, or by simple selection.
Techniques: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 will only be through values set in the WM. Note that some of your predicates may 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 two of the key runs provide a clear, self-explanatory "demonstration", 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:
How to submit:
Please note:
|