Action object parameters

[e-cal]

In manually constructing traces, I noticed an issue similar the the fluent-value one with Action.obj_params.

The Action constructor takes a name and a list of CustomObjects which the action acts on. By storing this on the Action itself, it isn't clear which object it actually acted in that step because the list either holds all the objects it could act on, or is overwritten each time the action occurs.

Multiple actions with the same name ("pick up" acting on A, "pick up" acting on B) could be used but as with the fluents that doesn't seem right.

This one doesn't affect model extraction, but makes it difficult to print action information.

As it is, can't determine which block was actually "picked up" from within the Action's __str__ method unless multiple "pick up" actions exist:

# test.py
pick_up = Action("pick up", obj_params = [blockA, blockB])

Trace(
  [
    Step(
      State(
        {
           a_clear: True,
           b_clear: True,
           a_on_table: True,
           b_on_table: True,
         }
       ),
         pick_up,
       ), 
       ...
  ]
)

# action.py
def __str__(self):
        string = f"{self.name} {' '.join(map(str, self.obj_params))}"
        return string

Output of printing the trace list:

I think the solution would be to store action parameters in Step,
ie Action(name) and Step(state, action, objs)
instead of Action(name, objs) and Step(state, action) as it is now.

But seeing as this doesn't pose a problem to model acquisition, maybe it is better to leave it and just leave out obj_params in the Action string?

[haz]

Not sure what the core problem is -- a ground action is one that combines the lifted action (identifiable by name) and the object parameters. I think a step makes sense still as a tuple of state / ground-action. The objects don't really relate to the state (at least not directly).

Is the issue that an action object is uniquely defined (__hash__) using the action name?

[beckydvn]

I see... is the Model storing grounded actions? I thought it would just be storing actions in a general sense (i.e. pickup an object of type block).

[beckydvn]

In which case, pick up would just be one action.

[beckydvn]

I suppose if you wanted to have both grounded and non-grounded actions available, then yes it makes sense to combine them and just have one "pick up A." I thought you were referring to combining them in the analysis stage, my bad :)

[haz]

Sorry I'm only getting to this conversation now :P.

We will eventually want the option for both. There may be cases down the road when multiple actions with the same name and parameters need to be kept separate during extraction because of certain types of execution uncertainty.

For now, I think it'd be ok to define the __eq__ (or at least the __hash__) as corresponding to the action+parameters. This will help in things like "give me all the triples with this ground action". When it comes time for the more sophisticated representation, we can subclass.

From the Python perspective, there may be multiple objects for (pickup A), but with the right __hash__ implementation, they'd only appear once in sets we care to create, comparisons we make, etc.

[e-cal]

Ok perfect, thanks for the advice guys!