Title operators that conditionally delete/add the same fact not implemented
Priority bug Status resolved
Superseder Nosy List emilkeyder, erez, florian, gabi, haz, jendrik, malte, mkatz, patrik
Assigned To florian Keywords
Optional summary

Created on 2010-11-10.18:37:45 by malte, last changed by gabi.

File name Uploaded Type Edit Remove
Kd.pddl malte, 2012-01-04.07:06:36 application/octet-stream
Kp.pddl malte, 2012-01-04.07:07:18 application/octet-stream
domain-sortnet_03.pddl patrik, 2012-12-16.03:00:10 application/octet-stream
domain.pddl malte, 2010-11-10.18:37:58 application/octet-stream
domain_blai.pddl emilkeyder, 2011-08-19.19:40:27 application/octet-stream
domain_guy.pddl erez, 2011-06-28.15:03:33 application/octet-stream
problem.pddl malte, 2010-11-10.18:38:06 application/octet-stream
problem_blai.pddl emilkeyder, 2011-08-19.19:40:46 application/octet-stream
problem_guy.pddl erez, 2011-06-28.15:03:55 application/octet-stream
sortnet_03.pddl patrik, 2012-12-16.03:00:31 application/octet-stream
msg2701 (view) Author: gabi Date: 2013-11-19.22:49:43
It looks like I accidentally deleted msg 2687. Here is it again (sorry that the 
history is now a bit mixed up):

"I ran an experiment on all tasks. The translation time (CPU time measured 
within block "Translating task:") is on average 0.018 seconds longer and in the 
worst case 0.4 seconds, so this appears uncritical. I always got the same file as with the old translator version (except for some trucks-
strips tasks, for which the translator output is non-deterministic already with 
the old code; cf. issue22).

However, there could be an efficiency issue in more general cases. My 
implementation "guards" negative conditional effects. Let for example V=v be a 
SAS+ variable/value pair for a propositional atom A and let formula phi denote 
the condition that any (original) add effect on V triggers. A conditional 
delete effect on atom A with condition psi is then translated to an effect "if 
psi and V=v and not phi then V=none-of-those". The potential problem lies in 
the "not phi" part because it gets expanded in the "multiply out conditions" 
code (cf. issue165).

A possible alternative would be to introduce axioms for "not phi". Since we plan
to change the translator output semantics anyway and this change would 
also solve this problem, I would prefer to stick to the current implementation 
despite the possible performance problems.

Any objections?"
msg2691 (view) Author: florian Date: 2013-11-19.14:11:58
msg2690 (view) Author: gabi Date: 2013-11-18.18:02:06
Ok, I marked this issue as ready for reviewing (Florian volunteered).

I also opened a new issue (issue397) for a different way of treating conditional
effects. Please put yourself on the nosy list there if you are interested.
msg2688 (view) Author: malte Date: 2013-11-17.21:41:46
If there are no performance issues with the existing IPC domains, I think that
any solution is fine, and I'd stick with what you propose.

In the long term, it would be nice to have a closer look at various ways of
compiling these things, and maybe a simple way to do it would be to have a
convention similar to PDDL's "add effect wins over delete effects" to avoid
having to encode these "non-triggering" conditions. Or maybe we should simply go
with a semantics where effects are processed sequentially and make sure that the
ones that should "win" according to PDDL semantics are mentioned last.

(But that's for the future -- maybe open an issue for this if you think it's a
good idea.)
msg2686 (view) Author: gabi Date: 2013-11-17.18:42:21
The situation appears not to be overly bad. I ran a few tests and most
heuristics deal with multiple conditional effects very well. Only the FF
heuristic and the landmark heuristic (lmcount) do not generate very good
estimates, but this is -- at least in the case of the FF heuristic -- a general
issue with conditional effects (cf. issue166).
msg2684 (view) Author: malte Date: 2013-11-16.21:59:16
I commented at issue86.
msg2682 (view) Author: gabi Date: 2013-11-15.16:56:20
I just realized that I added a comment on the related issue86 but there are far
fewer people on the nosy list. So I re-post it here again:

I reimplemented the translation of operators to fix this bug. One problem is
that now the translator can create operators with several conditional effects on
one variable that set the variable to different values (in this case the
conditions are mutually exclusive). This happens on all tasks attached to this

Previously the translator simply bailed out in these cases. The issue is that 
parts of the search component could rely on the fact that an operator can set a 
variable only to one possible new value.

The question is what we should do in these cases. Of course, we can multiply out
all possible combinations of values. However, this could lead to many operators
with lots of preconditions: first, there are exponentially many such
combinations, second, we would need to include negated effect conditions for the
other values as operator precondition and negating a finite domain "atom" V=v
means replacing it with a disjunction over all other values of V.

So I wonder whether this is really the right way to go. Maybe we should rather
use a similar procedure as for axioms and conditional effects, where search
components that do not support them simply raise an exception. 

What is everyone's opinion on this? Malte, do you have an idea which parts of 
the search component rely on the above assumption?
msg2381 (view) Author: patrik Date: 2012-12-16.03:02:56
Adding one more example (sortnet_03, generated by Hector's conformant->classical
planning compiler). The operator that triggers the assertion failure does not
have any conditional deletes. Some other operators in the domain do, however.
msg2012 (view) Author: malte Date: 2012-01-04.07:07:18
Attaching another test problem provided by Ronen Brafman and Guy Shani
msg1957 (view) Author: malte Date: 2011-11-15.22:07:03
See issue297.
msg1680 (view) Author: emilkeyder Date: 2011-08-19.19:41:53
Added another problem where the same issue appears, this one is one of Blai's 
compiled problems from the deriving finite state controllers paper.
msg1389 (view) Author: erez Date: 2011-06-28.15:03:33
I get the same problem (I think) when trying to run the planner on problems 
generated by a translation of contingent planning problems (I got the problems 
from Guy Shani), attached.
msg1229 (view) Author: gabi Date: 2011-01-25.17:03:01
If we have fixed it, we should also try whether this solves the problem reported
by Patrik around January 12, 2011 (Subject: FD translator bug).
msg842 (view) Author: malte Date: 2010-12-13.13:37:38
See also issue86.
msg841 (view) Author: gabi Date: 2010-12-13.13:37:22
This is the same bug as in issue 86.
msg701 (view) Author: malte Date: 2010-11-10.18:37:45
@Gabi, Jendrik: I'm nosying you FYI since you've worked on the translator
recently. Feel free to unnosy yourself. This is not directly related to the
invariant synthesis, although the underlying reason for this planner limitation
is. The code that needs to change here is in

The attached problem throws the assertion "Add effect with uncertain del effect
partner?", even after disabling invariant synthesis. Indeed this assertion is
correct: if we add an operator.dump() directly before the assertion, we get

(puton block_b block_a cylinder_a)
PRE: Atom on(block_b, block_a)
PRE: Atom free(block_b)
PRE: Atom free(cylinder_a)
ADD:  -> Atom on(block_b, cylinder_a)
ADD:  -> Atom free(block_a)
ADD: Atom at(cylinder_a, table_a) -> Atom at(block_b, table_a)
ADD: Atom at(cylinder_a, table_b) -> Atom at(block_b, table_b)
DEL:  -> Atom on(block_b, block_a)
DEL: Atom at(block_a, table_b), Atom at(cylinder_a, table_a) -> Atom at(block_b,
DEL: Atom at(block_a, table_a), Atom at(cylinder_a, table_b) -> Atom at(block_b,
DEL:  -> Atom free(cylinder_a)

so some state variables (e.g. at(block_b, table_a)) both have conditional add
effects and conditional delete effects. But of course this is a planner
limitation, not an error in the input, so we should fix this limitation.

In this case, we could simply throw away the conditional delete, since it's only
triggered in cases where the conditional add also triggers, and according to
PDDL semantics the add effect then wins.

More generally, however, we should support operators that can either delete or
add a fact, depending on context. The challenge then is to handle this correctly
in all heuristics (e.g. we need to be careful in abstraction heuristics -- but
ours currently don't support conditional effects anyway), for which it'd
probably be good to design some tests for the corner cases.
Date User Action Args
2013-11-19 22:49:43gabisetstatus: chatting -> resolved
messages: + msg2701
2013-11-19 22:33:23gabisetstatus: resolved -> chatting
messages: - msg2687
2013-11-19 16:57:07jendrikunlinkissue397 superseder
2013-11-19 14:11:58floriansetstatus: reviewing -> resolved
messages: + msg2691
2013-11-18 18:02:06gabisetstatus: testing -> reviewing
assignedto: gabi -> florian
messages: + msg2690
nosy: + florian
2013-11-18 17:59:38gabilinkissue397 superseder
2013-11-17 21:41:46maltesetmessages: + msg2688
2013-11-17 20:13:08gabisetstatus: chatting -> testing
messages: + msg2687
2013-11-17 18:42:21gabisetmessages: + msg2686
2013-11-16 21:59:16maltesetmessages: + msg2684
2013-11-15 16:56:20gabisetmessages: + msg2682
2013-03-22 15:02:42gabisetassignedto: gabi
2012-12-16 03:02:56patriksetnosy: + patrik
messages: + msg2381
2012-12-16 03:00:31patriksetfiles: + sortnet_03.pddl
2012-12-16 03:00:10patriksetfiles: + domain-sortnet_03.pddl
2012-01-13 17:01:54mkatzsetnosy: + mkatz
2012-01-04 07:07:18maltesetfiles: + Kp.pddl
messages: + msg2012
2012-01-04 07:06:36maltesetfiles: + Kd.pddl
2011-11-15 22:07:03maltesetmessages: + msg1957
2011-08-19 19:41:53emilkeydersetnosy: + emilkeyder
messages: + msg1680
2011-08-19 19:40:46emilkeydersetfiles: + problem_blai.pddl
2011-08-19 19:40:27emilkeydersetfiles: + domain_blai.pddl
2011-06-28 15:03:55erezsetfiles: + problem_guy.pddl
2011-06-28 15:03:33erezsetfiles: + domain_guy.pddl
nosy: + erez
messages: + msg1389
2011-01-25 17:03:01gabisetmessages: + msg1229
2010-12-22 19:16:29hazsetnosy: + haz
2010-12-13 13:37:38maltesetmessages: + msg842
2010-12-13 13:37:22gabisetmessages: + msg841
2010-11-10 18:38:06maltesetfiles: + problem.pddl
2010-11-10 18:37:58maltesetfiles: + domain.pddl
2010-11-10 18:37:45maltecreate