Non deterministic

[Timisorean]

Add support for :non-deterministic (and thus the oneof keyword).

This is done by modifying the structure of the AST:

         ┌─────────────── EffectRoot ─────────┐
         │                                    │
         ▼                                    ▼ 
EffectRootNonDeterministic──────────►EffectRootDeterministic

Here EffectRootDeterministicis equivalent to EffectRootbefore changes.

Additionally, the effect EffectOneof is introduced. It has one attribute, effects, which is a list of all the possible effects of the action.

TODO:

• Check compatibility in mimir. See: DRAFT: Prepare for non-deterministic merge of Loki simon-stahlberg/mimir#14

[drexlerd]

Hi Samuel,

I am not very familiar with the non-deterministic planning language and I am looking for a reference to readup a bit on the grammatic, can you share one?

Regarding making this available in Mimir, I think that the one-of effect can be compiled away, since it is basically a disjunctive effect. That would be perfect, since the planner performance in cases that do not use non-determistic actions will be unaffected. The question then becomes when the compilation should occur, i.e., can other compilation steps beforehand, result in a smaller size of the task. In any case, we should not add a new effect structure into Mimir if it can be avoided.

Thanks for the great work already!

[haz]

Maybe the earliest mention: https://icaps03.icaps-conference.org/satellite_events/documents/WS/ws3/03/bertoli.pdf

...and a BNF that already tackles it: https://github.com/AI-Planning/pddl/blob/main/pddl/parser/domain.lark#L48

...but a (oneof ...) isn't really a disjunctive effect (which doesn't really have a concrete definition). Disjunctive conditions are well defined, but not "disjunctive effects".

[drexlerd]

Thanks @haz.

@Timisorean looking at the grammar definition, the oneof effect should become a choice of effect_conditional_def, meaning that it can appear in several nested effects as well.

const auto effect_conditional_def = effect_conditional_forall | effect_conditional_when |effect_oneof;

and probably renaming it to

const auto effect_composite_def = effect_composite_forall | effect_composite_when | effect_composite_oneof;

This can make the integration into Mimir more complicated if it cannot be compiled into a "flat", i.e., non-circular, normal form. The serialization library that we use supports serialization of circular data structures but I never use that feature and it also supports serialization of variant.

[morxa]

Usually, oneofs can only occur as top-level effect and nested within other effects:

Additionally, in order to ease the development of parsers
for PPDDL, all operator schemata will be such that non-
determinism inside conditional effects and/or nested condi-
tional effects will not be allowed.

6th International Planning Competition: Uncertainty Part

Also looking at all the FOND domains here or here, we only see oneofs at the top level.

So while allowing arbitrary nestings may be nice, only allowing top-level oneofs should be enough and avoids the problems that you have mentioned.

[morxa]

Some background for this PR: We're currently using the pddl library mentioned by @haz for generalized FOND planning, but we eventually want to switch to and integrate it into mimir, e.g., to use the state space abstraction techniques. This PR is a first step towards that.

[haz]

Got it. For reference, we're hoping this builds out to be the canonical repository of all FOND domains: https://github.com/AI-Planning/fond-domains

More relevant, we're nearing a working initial status of some FOND utils that would be useful here: https://github.com/AI-Planning/fond-utils/tree/sardina-merge

You could use it as a stand-alone utility to process arbitrary FOND domains and have them normalized -- single top-level (oneof ...) clause with (and ...) children. With this in hand, you can assume all your problems will be normalized (increasingly with modern domains, that's not a safe assumption, so having the preprocessor is helpful).

[drexlerd]

Looking at the benchmarks and the current implementation of the grammar in the pull requests, there are some domains that cannot be parsed, see e.g., the action here which has an (and ...) at the root of the effect. In other words, the example contains deterministic and nondeterministic effects.

Given that there is code to normalize more complex nondeterministic effect structures, the future oriented solution is to make the syntax parser more general, as described above and in the grammar posted by Christian, and then normalize more complex expressions within the planner directly, and then throw errors if the input task goes beyond the supported fragment with a oneof at the root.

The current translator in Mimir is the one from Malte (Section 4: https://ai.dmi.unibas.ch/papers/helmert-aij2009.pdf). The normalizer by Christian currently does not consider universal effects, which can still be moved to the root after renaming of quantified variables, and is already done for you. The implementation of the flattening operation of oneof can be copied from other flattening operations.

I currently don't see any issues with generalizing the current approach. Any doubts?

p.s. The action structures (lifted and grounded) are currently still a bit messy but I will clean this up later to simplify the integration. Basically, I want to get rid of the special case of effects with zero quantified variables.

[haz]

The existing fond-utils does handle some level of quantification, but the full handling is not as simple as simple rewrites:

(forall (?x - bla) (oneof (f ?x) (g ?x)))

Flattening / normalizing this so that the only (oneof ...) is a single top-level means that you need to first expand the universal with all objects/constants (i.e., turn it into a conjunction), and then start doing the cross-product of terms.

I should probably point out, @drexlerd , that I'm just floating into the conversation as a FOND fan, and not related in any way to what @morxa is up to. Professional lurker, if you will ;). You're more than welcome to use fond-utils as a preprocessor that normalizes FOND domains, and then just define a grammar on the simplified version of FOND problems. Or not. Just don't want yas to re-invent the wheel, unless you really want to.

[drexlerd]

I want to learn more about FOND planning and become a fan too :)

Thanks a lot for the example. I understand now.

[Timisorean]

• Renamed ConditionalEffects to CompositeEffects
• Removed the Deterministic and NonDeterministic roots from before
• Now EffectOneOf is also a CompositeEffects
• This means that it can also appear nested
• Changed tests to also use domain which includes nested oneof

Please look at src/pddl/parser/effects.cpp lines 138-148 and check if this is correct, because I am unsure about those lines.