LOCM Differences

[haz]

Try as we may, there seem to be two hangups with our understanding of the original LOCM paper that are preventing a faithful reproduction.

Paper: http://eprints.hud.ac.uk/id/eprint/9052/1/LOCM_KER_author_version.pdf

Issue 1: Agressive Parameter Merges

The paper lists two conditions under which we would merge <h, v> parameters:

However, when we are extracting the fluents from an FSM state, we need to know which of the action arguments should map to the fluent arguments (i.e., each state parameter needs to reference a single parameter index from the action). If we can merge for both B and C reasons, we wind up with a collection of hypothesis bound to a single state parameter that vary in k' and l' values. This makes it ambiguous as to which index should be used.

Changing the "or" in this condition to an "and" gives us something far stronger of a condition, and that leads to more parameters ultimately being included. This flies in the face of the paper details, but we are yet unable to find a work-around.

Issue 2: Under-aggressive Flaw Detection

The flaw-detection procedure follows this reasoning:

If a sort has an action that is meant to set this object (go into a state), then it shouldn't have an indeterminate value for one of the parameters. However, it seems as though there is a similar case missing for reading the value of a parameter. Any transition out of a state should be able to refer to every one of that state's parameter set, and so a similar check for flaw removal be used for the outgoing edges.

This change was also required to make the implementation work, and it has the result of removing far more parameters than otherwise. This results in smaller fluents, especially as the data provided grows (giving us less meaningful models).

Possible Source of Issue

Both issues above stem from the assumption that a single state in an FSM should correspond to a single typed predicate. The first parameter of the object corresponds to the sort FSM, and the rest correspond to the parameters found on the state. This means that every incoming edge to a state in an FSM should have as an add effect the same typed predicate. Similarly, every action on an outgoing edge should share that same predicate definition.

How the action parameters correspond to the predicate parameters is individual (those bindings will change from one action to the next). But the 1-to-1 correspondence of FSM states and predicates in the domain is a driving force behind the difficulties we face with Issue 1 + 2. If this assumption is wrong, then that may be the source of confusion.

Current Remedy

We've fixed Issue 1 by replacing the or with an and, and we've fixed Issue 2 by identifying flawed parameters as those with an action that doesn't read it. Both of these fixes diverge from the original LOCM work.