o

Situation Calculus

methods-of-ai

Situation Calculus (McCarthy & Hayes, 1969) is a logical formalism for reasoning about actions and their effects in dynamic worlds. It’s the alternative to STRIPS-style planning: instead of representing states as sets of atoms and modifying them imperatively, Situation Calculus models time as a sequence of situations connected by actions, all inside First-Order Logic.

It’s the theoretical foundation of AI planning. STRIPS / PDDL are what you actually use in practice; Situation Calculus is what you learn for the exam to understand why STRIPS exists.

The three building blocks

1. Situations

Situations are terms (not states) that represent snapshots of the world at a point in time:

  • S₀ — the initial situation (a constant)
  • do(a, s) — the situation that results from performing action a in situation s

So do(put(A, B), do(pickup(A), S₀)) denotes the situation: from the start, pick up A, then put A on B.

2. Fluents

Fluents are predicates or functions whose truth value can change across situations. The situation is passed as an extra argument:

  • On(A, B, s) — “A is on B in situation s”
  • Clear(x, s) — “x has nothing on top of it in situation s”

Contrast with rigid predicates (don’t change over time): Block(A), Color(red).

3. Axioms

  • Action precondition axiom — when an action is possible:
    Poss(pickup(x), s) ↔ Clear(x, s) ∧ HandEmpty(s)
  • Effect axiom — what becomes true after an action:
    Poss(pickup(x), s) → Holding(x, do(pickup(x), s))
  • Frame axiom — what stays the same after an action:
    Color(x, c, s) → Color(x, c, do(a, s)) for every (action × fluent) pair that doesn’t change

⚠️ The Frame Problem in living color

Effect axioms are easy. Frame axioms are a nightmare: if you have n actions and m fluents, you potentially need O(n · m) frame axioms — one per (action, fluent) pair that doesn’t change.

Example: 5 actions, 10 fluents → up to 50 frame axioms, each something like “moving block A doesn’t change the color of block B.” Practically impossible at scale.

Two famous “fixes”:

FixIdeaLimitation
Reiter’s Successor State Axiom (1991)Combine all positive + negative effects on a fluent into one biconditionalElegant; standard textbook solution; still requires explicit specification per fluent
STRIPS’ closed-world assumption”Anything not in the ADD or DEL list of an action is unchanged”Sidesteps frame axioms syntactically — but ontological problem remains (see Frame Problem)

This is the whole reason STRIPS exists: trading some logical generality for practical tractability.

Worked mini-example

The blocks world. Initial situation S₀: A on table, B on table, C on A.

Fluents at S₀:
  OnTable(A, S₀), OnTable(B, S₀), On(C, A, S₀)
  Clear(B, S₀), Clear(C, S₀), HandEmpty(S₀)

Action: pickup(C)
  Preconditions: Clear(C, S₀) ∧ HandEmpty(S₀)  → satisfied
  Effects in do(pickup(C), S₀):
    Holding(C), Clear(A) become true
    HandEmpty, Clear(C), On(C, A) become false
  Frame (must be axiomatized):
    OnTable(A, do(pickup(C), S₀)),  OnTable(B, do(pickup(C), S₀))

To plan “stack C on B,” you do logical deduction: find a sequence of actions a₁, a₂, … such that the goal On(C, B, do(aₙ, do(aₙ₋₁, …, S₀))) is entailed by the axioms.

Situation Calculus vs. STRIPS

Situation CalculusSTRIPS
FormalismFirst-Order LogicSets of ground atoms
State representationSituation terms (do-chains)Set of atoms (closed world)
Frame problemExplicit frame axioms (or Reiter’s solution)Implicit (closed-world assumption)
Planning byLogical deduction (theorem proving)State-space or plan-space search
Used today forTheoretical analysis, GOLOG languagePDDL, real planners
StrengthsFull expressive power of FOLTractable, simple action schemas
WeaknessesFrame axiom explosionLimited expressivity (no functions, no nested negation)

⚠️ Exam trap: “STRIPS solves the Frame Problem.” → FALSE. STRIPS sidesteps it via the closed-world assumption + ADD/DEL lists. The underlying ontological challenge (knowing which things don’t change in the real world) is just pushed onto the modeler. See Frame Problem.

Where Situation Calculus is used today

  • GOLOG (Levesque et al., 1997) and ConGolog — programming languages built on Situation Calculus for robot control. Used in research robots.
  • Cognitive robotics — formal reasoning about action effects in long-horizon plans
  • Formal verification of planning systems — when you need to prove that a planner is correct
  • Modal logic + multi-agent systems — Situation Calculus extends to multi-agent settings, used in some game-theory reasoning systems
  • Action languages (A, B, C, K) — descendants of Situation Calculus, used in answer-set programming

Where Situation Calculus was replaced — and by what

DomainWas Situation Calculus, now …Why
Practical planningPDDL / STRIPSTractable; integer rather than first-order; supported by IPC competition planners (Fast Downward, LAMA)
Reasoning about uncertain actionsMDPs / POMDPsProbabilistic frameworks subsume deterministic action effects
Robot task and motion planningPDDL + sampling-based motion planners (RRT)Hybrid approaches scale better than pure logical inference
Knowledge representation about actionDescription Logics + temporal extensionsDLs are decidable; full Situation Calculus is undecidable

Where Situation Calculus still matters: as the theoretical reference for action representation, and in cognitive robotics where you need rigorous reasoning about long action sequences with effects on the world.

See also

Tags: methods-of-ai planning situation-calculus frame-problem
Created: 18-05-26