aibasel / pyperplan

A lightweight STRIPS planner written in Python.
GNU General Public License v3.0
93 stars 41 forks source link

Add support for :equality keyword #15

Closed bonetblai closed 2 years ago

bonetblai commented 2 years ago

Here is the pull request for the :equality keyword. This was more difficult since Pyperplan doesn't support negative preconditions; i.e., differently from effects where each action has an add and del list, preconditions are simply a list of Predicates() so it wouldn't be that easy to accommodate "native" negative preconditions such as (not (= ?x ?x))).

Therefore, I did the following "hacky" trick. When :equality is specified, two new predicates are created: "=" and "not=". Then, each instance of (not (= ?x ?x)) in preconditions is translated into (not= ?x ?x), thus removing the negation. Checks that raise errors for the use of "=" and "not=" in effects, and the use of (not <predicate>) in non-equality preconditions are done. Constructs like (not (not (?x ?x))) and (not (not= ?x ?x)) that are semantically right are refused, and constructs like (not= ?x ?x) are accepted.

On the other hand, the initial situation of a problem is extended with denotations for "=" and "not=". That is, the initial situation is extended with atoms (= o o) for each object o, and with atoms (not= o1 o2) for each pair of different objects o1 and o2.

I have tried to adhere to the style.

bonetblai commented 2 years ago

You can put this PR on hold for the moment as there is something additional to do. The removal of irrelevant operators must be done in two steps. In the first step, all operators whose preconditions are false given the static atoms are removed. In the second step, all operators that are irrelevant given the goal are removed. This because when you want to preserve irrelevant operators, you still want to execute the first step and disable the second. I'll work on this later and then do the complete PR.

jendrikseipp commented 2 years ago

Your comment sounds like it's about the pull request that's already merged, right? If so, it's best to work on this in a separate pull request.

Regarding the :equality keyword (this pull request), I think that the utility of the feature does not justify the added code complexity, especially since Pyperplan doesn't support negative preconditions. The goal for Pyperplan is to remain easily understandable by undergrads, and the proposed changes make this more difficult. So I propose that you add the :equality keyword in your private copy of Pyperplan.