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 
output.sas 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?"

merged

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.

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.)

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).

I commented at issue86.

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
issue.

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?

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.

Attaching another test problem provided by Ronen Brafman and Guy Shani
(Kd.pddl/Kp.pddl).

See issue297.

Added another problem where the same issue appears, this one is one of Blai's 
compiled problems from the deriving finite state controllers paper.

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.

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).

See also issue86.

This is the same bug as in issue 86.

@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 translate.py

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,
table_b)
DEL: Atom at(block_a, table_a), Atom at(cylinder_a, table_b) -> Atom at(block_b,
table_a)
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.