Model to PDDL

[beckydvn]

Hi there,

So, I was starting to work on the issue to convert a Model to tarski objects and then to PDDL. The problem that I ran into is that, since the Model stores all of its information in strings, it is difficult to parse that information in a meaningful way. For example, given on object c object e, there is no simple way to parse that on is a predicate that takes two arguments c and e of type object (given that, within Model, I have no information on what any of those words mean).

There are a couple handy functions in Generator (extract_action_typing and extract_predicate_typing) that would make this parsing really easy, but from what I understand, the extraction side of things is supposed to be completely isolated from the rest of the API. If that's out of the question, is there any better way to tackle this other than parsing strings?

[haz]

@e-cal Can you recall why it's stored as strings there?

From the Model side, i.e., what we extract, I think a string-based repr isn't our best option. So the fix would be improving the sophistication of the Model. Looking into it quickly, we may already be partway there?
https://github.com/QuMuLab/macq/blob/main/macq/extract/learned_action.py#L7

So which (python) objects, in particular are holding you back as being strings?

[haz]

Yep, precisely. I think ARMS is an example that dives a bit deeper with a specific purpose. So it will need the more sophisticated representation.

[TathagataChakraborti]

I started writing this comment having misunderstood the OP but now that I am halfway through it, bear with the first part first and then I will come back to the question 🙈

---

It very much depends on the planner what kind of string representation of plans you get. I think you should just specify at the level of an observation schema and have whoever is generating the observations conform to it i.e. they would have to write the adapter from their strings to something that matches the schema. Something of this sort.

class Variable(TypeDict):
    name: str
    value: Union[bool, str, float]
    
class ActionObservation(TypedDict):
    action_name: str
    grounded_parameters: List[Variable]

class StateObservation(TypedDict):
    state: List[Variables]

class Observation(TypedDict):
    observartion: Union[ActionObservation, StateObservation]

Now for the non-ugly planners (FF 😒) you can usually split on the spaces, and match back to the objects in the problem file to see what they are. Of course, if you are generating the traces yourself using your custom planner then might as well write directly to whatever scheme you chose to support.

---

Coming back to the question on the string representation of models, I think the only thing the API should have is the model schema similar to above of what the API supports as outputs and have the Tarski write to PDDL based on that schema. It should be the responsibility of individual algorithms to output to the same schema and invoke model.write_to_pddl() -- so parsing is algorithm level, not MAcq level imo.

[haz]

"algorithm" == ??. If it's, for example, SLAF/ARMS/etc, then that is MaCq.

Plan parsing? Done server side -- we get the list of actions, and have a trace generated just fine in our original trace representation (which we then tokenize (then extract (then write to PDDL))).

The OP was on what the extraction method is expecting. If you have a Fluent as an object with it's predicate name + objects in slots, then that's different than a single string representation.

I realize this is a bummer-of-a-refactor, but I think I misled with my comments above on the fork in the road. We likely still want everything as Fluent objects, but one form will have all the arguments flattened into the predicate name. So (on blockA blockB) may be represented as either...

{
    "name": "on",
    "arguments": [
        {"object": "blockA", "type": "block"},
        {"object": "blockB", "type": "block"}
    ]
}

...or...

{
    "name": "on_blockA_blockB",
    "arguments": []
}

...depending on the tokenization that has happened. SLAF cares for the latter; ARMS cares for the former. And ya, this is JSON-y representation when in fact it'd be Python objects.

[TathagataChakraborti]

"algorithm" == ??. If it's, for example, SLAF/ARMS/etc, then that is MaCq.

Is it?! Shouldn't those be just algorithm options inside MAcq?

Plan parsing? Done server side -- we get the list of actions, and have a trace generated just fine in our original trace representation (which we then tokenize (then extract (then write to PDDL))).

I don't think this is the use case all the time. Someone could have come in with a bunch of traces hoping MAcq can give them a model. As I was saying, if we are the ones generating the trace then we can write to that schema as well but in general it should be a schema people are writing to ...

The OP was on what the extraction method is expecting. If you have a Fluent as an object with it's predicate name + objects in slots, then that's different than a single string representation.

... and that applies to fluent representation as well. So it should always be of the form (1) and algos like SLAF can just derive (2) from it.

[haz]

Is it?! Shouldn't those be just algorithm options inside MAcq?

But what is mACq?? It is all of the above and more. Succinctly, the file structure shows you: generation, trace representation, observation/tokenization, and extraction.

So it should always be of the form (1) and algos like SLAF can just derive (2) from it.

Kinda...SLAF might want the same as something else. This is why we have observation/tokenization separate. The conversation here is mainly centred around that observation/tokenization setup. We have high-fidelity trace representations coming in (from being generated, but that matters not), and competing extraction techniques that have a different notion of "fluent".

Discussions in this space are comically ambiguous because of the (necessary) layers of representation: an action or fluent may be one in the original trace representation, one in the tokenized version, one in the learned representation after extraction, or one in the generated/dumped plan. There are concrete cases where each has its own unique representation.

Welcome to the circus! 🤡

[haz]

Ok, @e-cal et al., let's think this one through. I see two prevailing options right now:

Use AtomicPartialObservation

• It would inherit from PartialObservation
• Get access to the random_subset for free
• Access to the fluents/actions auto-magically atomicizes

Don't use AtomicPartialObservation

• Would mean having special "atomic" functions (as @e-cal suggested) for the fluents/actions.
• Extraction techniques would call this special functionality.

Thoughts

Reason I was wary of the latter is that it starts to have features creep in on our Fluent and Action class. But now I'm pretty 50/50 on this being a common-enough feature to warrant it.

What do y'all think?

[beckydvn]

I feel like it makes more sense to have AtomicPartialObservation separate so that it's more clear what information the extraction techniques are using (and they don't have access to extra information that they shouldn't/don't need). Probably not a big deal if they do though. What do you think?

[e-cal]

The only disadvantage I see to the second is it removes the clear-cut distinction between atomic vs non-atomic. I don't really see why we would want to throw away potentially useful information if it isn't necessary, and why we need a distinction if the atomic representation doesn't interfere with the complete representation. Also because its just another representation of the same information, I don't see it as a bloating feature any more than .details() or __str__ are.

To atomicize without AtomicPartialObservation, I picture something like having a property action.atomic that defaults to None, and a function action.get_atomic() to fill in the property.

This could be called when tokenizing with trace_list.tokenize(PartialObservation, atomic=True). This way, you could still differentiate atomic or not by checking if action.atomic is None.

Or the atomic property could just be filled in no matter what, and its just up to us to know to access the right property in the extraction technique. This way both SLAF and ARMS could be run on the same observations (assuming they came from pddl - the atomic source data problem can be handled easily with a check at the start of ARMS and other non-atomic methods).

[haz]

So I've had a solid think on this...from just the pragmatic/engineering standpoint, there's no reason for separating. But to tie it directly to the rhetoric going into the paper (array of observation types, conversions between them, etc, etc.), I think we should run with the separate AtomicPartialObservation class for now.

As mentioned above, it really should be minimal in form since it inherits from PartialObservation.

Sorry it took so long to settle on this, and thanks both for the discussion around it!