Unfortunately, I'm not familiar with the code anymore by now :-). Since I don't
plan to work on this in the near future, I'm unassigning myself. You can find
the latest version of the issue397 branch at
https://bitbucket.org/jendrikseipp/downward/branch/issue397 .

I re-assigned this to Jendrik because he currently is much more familiar with
the code than I am.

If it's fine with you, Gabi, I'd open a pull request for this issue.

I updated the patch. It now calls "SASOperator._canonical_pre_post()" again, but 
preserves the required order of effects.

Since I'd like to use the changes from this issue for IPC 2018, I have merged the 
current default branch from the master repository into the issue397 branch from 
Gabi's IPC 2014 repository. You can find the result at 
https://bitbucket.org/jendrikseipp/downward/branch/issue397 . I had to remove the 
call to "SASOperator._canonical_pre_post()" since it reorders the effects (this 
was introduced in issue533). If we decide to merge issue397, we should probably 
delete the "SASOperator._canonical_pre_post()" method. However, we should also 
think about whether we want to remove duplicate effects as is done in 
"SASOperator._canonical_pre_post()". I'm not sure whether any other changes to 
the translator since January 2014 interfere with the changes in the issue397 
branch.

I wondered if this had been addressed by some translator changes from a while
ago. Perhaps it has.

I did a local experiment on suite_satisficing_with_ipc11 and
suite_optimal_with_ipc11 and did not find any task with this condition. Maybe we
live in a better world than we thought.

Can you find out in which domains these occur? Maybe we can then implement the
comment from the function:

            // In a better world, these would never be included in the
            // input in the first place.

The check in verify_no_cond_effects() also is no longer valid under the new
semantics (as we discussed offline). I removed it for now. Did we discuss an
alternative that allows to recognize unproblematic special cases?

Under the new semantics, you can only do this if no earlier effect can change
the value of that variable to something else.

Just to make this clear: in the example in msg2881, removing the effect
condition {x=2} would not change the operator because effect 2 would trigger
whenever the operator is applied, independently of this effect condition.

However, I just had a look at the code and in translate.py lines 296-297 an
effect is dropped if it sets the variable to the same value as required by the
precondition. At the moment, I do not see why we can do this.

Sorry for the spam, Florian just told me that first all effects that trigger are 
collected and only in a second step their effects are applied.

In the issue397 branch in the IPC repo effect conditions that are also preconditions are removed. Is 
this still valid for the new semantics? Consider the following operator:

precondition: {x=2}
effect1: {} -> x=3
effect2: {x=2} -> {y=3}

If we remove the effect condition from effect2 both effects will trigger when the action is applied, 
otherwise only effect1 will trigger (assuming effect2 is evaluated after effect1).

OK, let's make it part of the input then.

I do not think we can cheaply regain this information in the search component.
In the translator we know that two effects on a variable that stem from PDDL add
effects will never trigger together (otherwise the invariant synthesis would be
incorrect). However, for finding this out we would need to use all mutex
information again.

I think this is a good idea.

I would suggest to do implement this marking directly in the search component
rather than have it be present in the input. (In general, we want to be able to
verify that the input makes sense, and for this we'd be able to verify such
markings in the input anyway. And then we might as well recompute them.)

I just started working on the sequential evaluation of effects. 

I think it would make sense to mark effects that can possibly be overwritten by
later effects as such. This would allow a protecting flag for heuristics that do
not support the new semantics. In addition, for heuristics that do support the
new semantics, knowing that an effect won't be overwritten can save overhead.

What do you think?

I removed issue146 from the "replaced by" list since otherwise the issue doesn't 
appear in the overall list of open issues.

Currently the translator ensures that the effect conditions of all effects on
the same variable are mutually exclusive. However, this can significantly
increase the size of the operator, so a different way of treating conditional
effects could be helpful.

Gabi in issue146:
"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)."

Malte in issue146:
"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."