For now I've added a comment about the two unsolvable tasks to lab's 
downward.suites.suite_unsolvable(). If they become part of FD's benchmarks, we 
can add them to the list returned by this function.

The code has been merged and pushed.

Please do. (It might make sense to collect the information which tasks are
unsolvable somewhere, if someone wants to do that.)

Héctor confirmed that t0-uts/uts_r-02.pddl is unsolvable and he assumes that the 
translated version of prize-5x5R is unsolvable as well, so I propose we go ahead 
and merge this, ok?

The original formulation (with the one-of function) of t0-uts/uts_r-02.pddl is 
unsolvable by my reasoning. I wrote an email to Héctor Palacios.

I have trust in configurations like astar(blind()) to do the right thing, but
we've had bugs in the translator and preprocessor before related to these
compiled problems. I was in touch with Hector Palacios and Alexandre Albore
about one such bug only two weeks ago.

I hope the "prize-5x5R" example should be easy enough to understand in its
original non-compiled form. What is the source of the benchmark? Maybe it's
easiest to contact the authors.

I also tried running ehc (with blind or hm(m=1)) on the problems to see if the
initial state is a dead end (in which case ehc proves unsolvability), but this
did not work.

It seems however that these task are indeed unsolvable, reading Jendrik's and
Florian's messages. I think the patch is fine.

Both implementations of LM-Cut for conditional effects and h^max also report
these tasks as unsolvable. Compiling away the conditional effects and using
standard LM-Cut does so, too.

Both problems cannot be solved by any of astar(blind()), lazy_greedy(ff()), 
lazy_greedy(cea()) and original FF v2.3. All planners report that the search 
space has been completely explored. A manual analysis is complicated, because 
even the smaller task (from t0-uts) is quite involved and I know nothing about 
its nature. I'm attaching the two tasks nonetheless.

I am happy to have a look at the diff (will do so tomorrow).

> Thanks! If someone (other than me) can sign off on the diff for the branch,
> I'm fine with having it merged.

...after we've checked what's going on in the two unsolved tasks.

I changed the docs to use your note instead.

Thanks! If someone (other than me) can sign off on the diff for the branch, I'm
fine with having it merged.

However, I'd like the documentation for the conditional effect support to be a
bit more high-level. Maybe something like "supported (but see note)" and a note
saying something like:

Conditional effects are supported directly. Note, however, that for tasks that
are not factored (in the sense of the JACM 2014 merge-and-shrink paper), the
atomic abstractions on which merge-and-shrink heuristics are based are
nondeterministic, which can lead to poor heuristics even when no shrinking is
performed.

I updated the pull request at 
https://bitbucket.org/jendrikseipp/downward/pull-request/9/basic-conditional-
effect-support-for-merge/diff 
and added some basic documentation about the conditional effect support. I also 
cherry-picked Florian's verify_no_axioms_and_no_cond_effs() refactoring into the 
issue branch.

> Now M&S only reports two tasks as unsolvable, but for these h^blind also fails
> to find a solution.

Are these tasks unsolvable? If not, there's another bug somewhere.

> I think this could be merged. What do you think?

I would need to have a look at the code. Where is it? The last version I saw
wasn't ready to merge. For example, it had no user documentation about the
nature and limitations of conditional effect support.

I ran an experiment with the fixed conditional effect support for M&S: 
http://ai.cs.unibas.ch/_tmp_files/seipp/adl-domains.html

Now M&S only reports two tasks as unsolvable, but for these h^blind also fails 
to find a solution. 
Overall lmcut with conditional effect support seems to outperform M&S. In the 
cases where M&S is faster than lmcut, h^blind is usually faster than both of 
them. Only in t0-uts M&S is the best performing heuristic both time- and 
coverage-wise.

I think this could be merged. What do you think?

I added some comments at Bitbucket.

I had a look at the code and could not find any obvious errors (it's a *very*
small change anyway). I think we can use it for the competition and we may even
integrate it into the default branch, as the strips-behavior of m&s should not
be changed at all.

I had pushed the code and made the pull request in my downward repo and only 
later realized that it might be easier if I used the IPC repo directly. There's 
now a new pull request in the IPC repo with more reviewers ;)

Experiments showed that the implementation never finds worse plans than h^max 
and h^blind, but I would feel better after someone else had a look at the code 
before we use it for the competition.

I opened a pull request on bitbucket.

For the IPC it would be nice to have *basic* conditional effect support in the merge-and-shrink 
heuristic.