In artificial intelligence, with implications for cognitive science, the frame problem describes an issue with using first-order logic to express facts about a robot in the world. Representing the state of a robot with traditional first-order logic requires the use of many axioms that simply imply that things in the environment do not change arbitrarily. For example, Hayes describes a "block world" with rules about stacking blocks together. In a first-order logic system, additional axioms are required to make inferences about the environment (for example, that a block cannot change position unless it is physically moved). The frame problem is the problem of finding adequate collections of axioms for a viable description of a robot environment.[1]
John McCarthy and Patrick J. Hayes defined this problem in their 1969 article, Some Philosophical Problems from the Standpoint of Artificial Intelligence. In this paper, and many that came after, the formal mathematical problem was a starting point for more general discussions of the difficulty of knowledge representation for artificial intelligence. Issues such as how to provide rational default assumptions and what humans consider common sense in a virtual environment.[2]
In philosophy, the frame problem became more broadly construed in connection with the problem of limiting the beliefs that have to be updated in response to actions. In the logical context, actions are typically specified by what they change, with the implicit assumption that everything else (the frame) remains unchanged.
The frame problem occurs even in very simple domains. A scenario with a door, which can be open or closed, and a light, which can be on or off, is statically represented by two propositions
open
on
open(t)
on(t)
\negopen(0)
\negon(0)
open(1)
The first two formulae represent the initial situation; the third formula represents the effect of executing the action of opening the door at time 1. If such an action had preconditions, such as the door being unlocked, it would have been represented by
\neglocked(0)\impliesopen(1)
executeopen(t)
\forallt.executeopen(t)\impliesopen(t+1)
While the three formulae above are a direct expression in logic of what is known, they do not suffice to correctly draw consequences. While the following conditions (representing the expected situation) are consistent with the three formulae above, they are not the only ones.
\negopen(0) | open(1) | |
\negon(0) | \negon(1) |
Indeed, another set of conditions that is consistent with the three formulae above is:
\negopen(0) | open(1) | |
\negon(0) | on(1) |
The frame problem is that specifying only which conditions are changed by the actions does not entail that all other conditions are not changed. This problem can be solved by adding the so-called “frame axioms”, which explicitly specify that all conditions not affected by actions are not changed while executing that action. For example, since the action executed at time 0 is that of opening the door, a frame axiom would state that the status of the light does not change from time 0 to time 1:
on(0)\iffon(1)
The frame problem is that one such frame axiom is necessary for every pair of action and condition such that the action does not affect the condition. In other words, the problem is that of formalizing a dynamical domain without explicitly specifying the frame axioms.
The solution proposed by McCarthy to solve this problem involves assuming that a minimal amount of condition changes have occurred; this solution is formalized using the framework of circumscription. The Yale shooting problem, however, shows that this solution is not always correct. Alternative solutions were then proposed, involving predicate completion, fluent occlusion, successor state axioms, etc.; they are explained below. By the end of the 1980s, the frame problem as defined by McCarthy and Hayes was solved. Even after that, however, the term “frame problem” was still used, in part to refer to the same problem but under different settings (e.g., concurrent actions), and in part to refer to the general problem of representing and reasoning with dynamical domains.
The following solutions depict how the frame problem is solved in various formalisms. The formalisms themselves are not presented in full: what is presented are simplified versions that are sufficient to explain the full solution.
This solution was proposed by Erik Sandewall, who also defined a formal language for the specification of dynamical domains; therefore, such a domain can be first expressed in this language and then automatically translated into logic. In this article, only the expression in logic is shown, and only in the simplified language with no action names.
The rationale of this solution is to represent not only the value of conditions over time, but also whether they can be affected by the last executed action. The latter is represented by another condition, called occlusion. A condition is said to be occluded in a given time point if an action has been just executed that makes the condition true or false as an effect. Occlusion can be viewed as “permission to change”: if a condition is occluded, it is relieved from obeying the constraint of inertia.
In the simplified example of the door and the light, occlusion can be formalized by two predicates
occludeopen(t)
occludeon(t)
\negopen(0)
\negon(0)
open(1)\wedgeoccludeopen(1)
\forallt.\negoccludeopen(t)\implies(open(t-1)\iffopen(t))
\forallt.\negoccludeon(t)\implies(on(t-1)\iffon(t))
In general, every action making a condition true or false also makes the corresponding occlusion predicate true. In this case,
occludeopen(1)
t=1
open(t-1)\iffopen(t)
t=1
open
In order for this condition to work, occlusion predicates have to be true only when they are made true as an effect of an action. This can be achieved either by circumscription or by predicate completion. It is worth noticing that occlusion does not necessarily imply a change: for example, executing the action of opening the door when it was already open (in the formalization above) makes the predicate
occludeopen
open
open
This encoding is similar to the fluent occlusion solution, but the additional predicates denote change, not permission to change. For example,
changeopen(t)
open
t
t+1
\negopen(0)
\negon(0)
\negopen(0)\implieschangeopen(0)
\forallt.changeopen(t)\iff(\negopen(t)\iffopen(t+1))
\forallt.changeon(t)\iff(\negon(t)\iffon(t+1))
The third formula is a different way of saying that opening the door causes the door to be opened. Precisely, it states that opening the door changes the state of the door if it had been previously closed. The last two conditions state that a condition changes value at time
t
t
The value of a condition after the execution of an action can be determined bythe fact that the condition is true if and only if:
A successor state axiom is a formalization in logic of these two facts. Forexample, if
opendoor(t)
closedoor(t)
t
\negopen(0)
\negon(0)
opendoor(0)
\forallt.open(t+1)\iffopendoor(t)\vee(open(t)\wedge\negclosedoor(t))
This solution is centered around the value of conditions, rather than theeffects of actions. In other words, there is an axiom for every condition,rather than a formula for every action. Preconditions to actions (which are notpresent in this example) are formalized by other formulae. The successor stateaxioms are used in the variant to the situation calculus proposed byRay Reiter.
The fluent calculus is a variant of the situation calculus. It solves the frame problem by using first-order logicterms, rather than predicates, to represent the states. Convertingpredicates into terms in first-order logic is called reification; thefluent calculus can be seen as a logic in which predicates representing thestate of conditions are reified.
The difference between a predicate and a term in first-order logic is that a term is a representation of an object (possibly a complex object composed of other objects), while a predicate represents a condition that can be true or false when evaluated over a given set of terms.
In the fluent calculus, each possible state is represented by a term obtained by composition of other terms, each one representing the conditions that are true in state. For example, the state in which the door is open and the light is on is represented by the term
open\circon
open\circon
state(open\circon,10)
10
The solution to the frame problem given in the fluent calculus is to specify the effects of actions by stating how a term representing the state changes when the action is executed. For example, the action of opening the door at time 0 is represented by the formula:
state(s\circopen,1)\iffstate(s,0)
The action of closing the door, which makes a condition false instead of true, is represented in a slightly different way:
state(s,1)\iffstate(s\circopen,0)
This formula works provided that suitable axioms are given about
state
\circ
state(open\circs\circopen,t)
s
t
The event calculus uses terms for representing fluents, like the fluent calculus, but also has one or more axioms constraining the value of fluents, like the successor state axioms. There are many variants of the event calculus, but one of the simplest and most useful employs a single axiom to represent the law of inertia:
holdsAt(F,T2)\leftarrow
[happensAt(E1,T1)\wedgeinitiates(E1,F,T1)\wedge(T1<T2)\wedge
\neg\existsE2,T[happensAt(E2,T)\wedgeterminates(E2,F,T)\wedge(T1\leqT<T2)]
The axiom states that a fluent
F
T2
E1
F
T1
E2
F
T1
T2
To apply the event calculus to a particular problem domain, it is necessary to define the
initiates
terminates
initiates(opendoor,open,T).
terminates(opendoor,closed,T).
initiates(closedoor,closed,T).
terminates(closeddoor,open,T).
To apply the event calculus to a particular problem in the domain, it is necessary to specify the events that happen in the context of the problem. For example:
happensAt(opendoor,0)
happensAt(closedoor,3)
To solve a problem, such as which fluents hold at time 5?, it is necessary to pose the problem as a goal, such as:
\existsFluent[holdsAt(Fluent,5)].
In this case, obtaining the unique solution:
Fluent=closed.
The event calculus solves the frame problem, eliminating undesired solutions, by using a non-monotonic logic, such as first-order logic with circumscription[3] or by treating the event calculus as a logic program using negation as failure.
The frame problem can be thought of as the problem of formalizing the principle that, by default, "everything is presumed to remain in the state in which it is" (Leibniz, "An Introduction to a Secret Encyclopædia", c. 1679). This default, sometimes called the commonsense law of inertia, was expressed by Raymond Reiter in default logic:
| R(x,s) : R(x,do(a,s)) | |
| R(x,do(a,s)) |
(if
R(x)
s
R(x)
a
R(x)
Steve Hanks and Drew McDermott argued, on the basis of their Yale shooting example, that this solution to the frame problem is unsatisfactory. Hudson Turner showed, however, that it works correctly in the presence of appropriate additional postulates.
The counterpart of the default logic solution in the language of answer set programming is a rule with strong negation:
r(X,T+1)\leftarrowr(X,T), \hbox{not}\simr(X,T+1)
(if
r(X)
T
r(X)
T+1
r(X)
Separation logic is a formalism for reasoning about computer programs using pre/post specifications of the form
\{precondition\} code \{postcondition\}
Separation logic employs a tight interpretation of pre/post specs, which say that the code can only access memory locations guaranteed to exist by the precondition.[7] This leads to the soundness of the most important inference rule of the logic, the frame rule
| \{precondition\ | |
| code \{postcondition\} |
}{\{precondition\astframe\} code \{postcondition\astframe\}}
The frame rule allows descriptions of arbitrary memory outside the footprint (memory accessed) of the code to be added to a specification: this enables the initial specification to concentrate only on the footprint. For example, the inference
| \{\operatorname{list | |
| (x)\} code \{\operatorname{sortedlist}(x)\} |
}{\{\operatorname{list}(x)\ast\operatorname{sortedlist}(y)\} code \{\operatorname{sortedlist}(x)\ast\operatorname{sortedlist}(y)\}}
captures that code which sorts a list x does not unsort a separate list y, and it does this without mentioning y at all in the initial spec above the line.
Automation of the frame rule has led to significant increases in the scalability of automated reasoning techniques for code,[8] eventually deployed industrially to codebases with tens of millions of lines.[9]
There appears to be some similarity between the separation logic solution to the frame problem and that of the fluent calculus mentioned above.
Action description languages elude the frame problem rather than solving it. An action description language is a formal language with a syntax that is specific for describing situations and actions. For example, that the action
opendoor
opendoor
open
\neglocked
The semantics of an action description language depends on what the language can express (concurrent actions, delayed effects, etc.) and is usually based on transition systems.
Since domains are expressed in these languages rather than directly in logic, the frame problem only arises when a specification given in an action description logic is to be translated into logic. Typically, however, a translation is given from these languages to answer set programming rather than first-order logic.