Reference no: EM132378652

Introduction

Note that in this document, we will use the terms "action" and "operator" interchangeably.

In assignment 3, the domain knowledge was separated out from the search knowledge. However, for each new domain you still had to write prolog code to generate successors, etc. In this assignment, we are exploring how to standardise the representation of states and successor knowledge, so that no programming is needed to change domains. Instead, the domain actions are described declara- tively, and the states and goals are described using a variation of logic notation. States are conjunctions of positive literals, e.g., [at(houston), unvisited(dallas), unvisited(austin)]|, is a conjunction of those 3 literals. Goals are conjunctions of positive and negative literals, [at(houston], not(unvisited(dallas) )].

We introduce a new term, step, which is a record data structure defined in planning.pl as step(opName, opParams, stepCost) where:
• opName is the name of an action,
• opParams is a binding list for its parameters, i.e., the values associated with each of that actions variables,
• stepCost with is the cost of that action when used with that binding list.

The heart of domain independent planning is being able to:

1. check whether a list of goal literals is satisfied by a state;

2. determine whether a state satisfies the problem's goal.

3. determine which steps are applicable to a state;

4. apply an applicable step to a state to produce a new state;

Your assignment is code up these 4 core pieces for a domain-independent planner. You might find it easiest if you develop and test the code in the order presented above. These 4 predicates will be specified in more detail in the next section.

What you need to do

First, we need to clear up some terminology.

predicate a term of the form predName(Argument' ) where "Argument " in- dicates there may be zero or more arguments, where argument may be a bound or unbound variable, or a constant. Example: not(edge(dallas, City, 3)) is a predicate with predname not, and one argument, edge(dallas, City, 3), and that argument itself is a predicate with 3 arguments, dallas, City, and 3.

literal a predicate with no unbound variables. negative predicate a not predicate as shown in example above.

There are 4 predicates mentioned in the Introduction, which you need to write the code for:

1. satisfy(+Goals, +State)
2. satisfyGoal (+State)
3. op_Applicable(+State, ?0pName, ?Params)
4. op_ApplyOp(+0ldState, +Step, ?NewState)

where:
• Goal is predicate, e.g., unvisited(houston),
• Goals is a list containing the list of Goal
• State is an ordered set (ordset library) of predicates,
• OpName is the name of an op specified in tsp/domain.p],
• Step is an instance of a step data structure as described in the step record declaration in planning.pl,
• Params is the binding list, a list of the values to be bound to the variables in the preconditions and effects.

Goal and State are as described in the lectures. For example, a State data structure will only have positive fluents.

State is used as the index into closed list. It is used to detect duplicate states and to retrieve the solution. This requires that states have a canonical description (i.e., a unique representation, a 1-to-1 correlation between a state and its representation), which is why states are stored as ordered sets. Whenever you create a new state, you must ensure that it is still represented as an ordered set!

As mentioned in the lectures, the static predicates are stored in the problem's initial state description. For this assignment, this information is stored in the InitialState field in the predicate, problem(problemName, InitialState, Goals), in the prolog database.

Predicate Specification

(a) satisfies(+Goal, +State) Goal is a predicate. Examples of use of satisfies: e satisfies(edge(a, b, 3), State) @ satisfies(not(at(c)), State) What it means for a State to satisfies a Goal depends upon what type of goal it is, if the goal is a: @ positive fluent goal then it means Goal is an element of State @ positive static goal then it means that Goal is an element of the problem's initial state. @ positive metaLevel goal then it is defined by prolog code that needs to be called. ® negative goal, i.e., it is not(/Goal), then it means that Goal fails, regardless of which type of Goal it is.

(b) satisfy(+Goals, +State) Goals is a list of Goal. A State satisfy Goals iff State satisfies every Goal in Goals. State satisfyGoal iff State satisfy every goal in the problem's Goal list. The problem's Goal list is stored in problem. To access it, just execute "problem(, , Goals)" and Goals will be bound to the problems Goal list.

(c) op_Applicable(+State, ?OpName, ?Params) OpName with Params is op_Applicable iff the Preconditions for Op- Name bound with the Params binding list makes satisfy(Preconditions, State) true.

(d) op_ Apply(+0ldState, +Step, ?NewState) NewState is op_Apply to OldState via Step iff using NewState = OldState - Step's negative Effects + Step's positive Effects. In other words, The step's negated effects are deleted from OldState and the positive effects are added to form New/State. For example, if OldState = /fat(a), unvisited(b), unvisited(c)/, the negative effects = /not(at(a)), not(unvisited(b)/, and the positive ef- fects = /at(b)/ then NewState = /at(b), unvisited(c)]. Note that even though the negative efects had not around them, it was their en- closed predicate that was deleted, e.g., not(at(a)) deleted at(a) from the NewState list. Also note that NewState must be an ordered set, L.e., passes the is_ordset(+Term) test (see ordset library documen- tation).

Attachment:- Specifications.rar