If we ignore the schedule domain, the overall performance stays more or less the
same. But in schedule, we previously solved 148 instances and after the change
we solve only 139 (losing 9 tasks). I did a quick experiment with the current
revision on schedule and the yY configuration there solved 149 instances, so
this seems to be resolved by some other changes again. 

Since other implementations are already registered as a wish (issue111), this
issue is resolved.

here come the results.

ok, then I'll just run the two configs with yY search again.

I am just interested into a comparison of 4687-3842-3842-yY to 4703-3842-3842-yY.
If you still have the experimental results for 4703-3842-3842-yY, I am fine with
running only 4687-3842-3842-yY.

Do I have to run all versions plus the new one again, or just the new one?

> Jendrik, may I ask you to also run experiments with translator revision r4687?

If you start this before the 21st, please set to low priority (qalter -p -2 JOBID).

Hm, it's hard to evaluate the change for this issue with the current experiment
results because there have been several changes between the revisions. Jendrik,
may I ask you to also run experiments with translator revision r4687?

Here come the new reports with the requested improvements.

Done.
> The old result scripts printed normalized
>     summaries as well as non-normalized summaries at the end, and I think this
>     is a good idea.
Done.
>     Also, in both non-normalized and normalized summary tables, it would be good
>     to show the number of instances in each domain next to the domain name
Done.

I generally prefer PDF to TEX. The reports look great; just a few comments:

1. The "best" column currently gives the maximum over all columns, but we really
   should *minimize* time, expansions and cost.

2. When applying the IPC-2008 scores to pre-IPC-2008 domains, which have wildly
   differing instances numbers (e.g. 5 in Grid and 150 in Miconic-STRIPS), we
   usually normalize by domain. The old result scripts printed normalized
   summaries as well as non-normalized summaries at the end, and I think this
   is a good idea.

   In the normalized tables, the scores for each config/domain entry should be
   multiplied by 100 and divided by the number of problems in the domain, and
   the overall values in the last row should be averages, not sums. (With this
   normalization, all entries are always in the range 0-100.)

   Also, in both non-normalized and normalized summary tables, it would be good
   to show the number of instances in each domain next to the domain name
   (e.g. in tiny font or in parentheses) like we do in most papers. This helps
   spot experiment errors where some instances are missing, which we've had
   happen a lot in the past.

Regarding this particular issue, I'll leave it to Gabi to comment on whether we
can close it based on the results in Jendrik's reports.

I made some ipc style reports. Please have a look at the data and tell me if you 
think there could be flaws in my scripts. Do you need more reports? Do you want 
them in pdf or tex format?

Since Jendrik is running the experiments, I assign this issue to him (at least
for the moment).

I see. Can we get the per-task results (either on all tasks including the ones
not solved by everyone, or using an IPC-style output)?

It's interesting to see so many (small) decreases in performance in cases which
don't actually *have* negative preconditions, where as far as I understand
nothing should change. Maybe some performance issue was introduced at some point
in between. Oh well.

(This is not urgent, as we don't have to support negative preconditions for the
IPC. On the other hand, this looks almost done.)

The experiment also compares changes in the translate-andrew branch.

The experiments use these configurations:

 * 3827-3842-3842-yY
 * 3829-3842-3842-yY
 * 3840-3842-3842-yY
 * 4283-3842-3842-yY
 * 4703-3842-3842-yY

Why these particular ones? It seems to me that the first three of these should
be absolutely identical since there were no changes to the translator between
r3827 and r3840. Am I missing something?

here are the results.

I possibly erased the results. Will run a new experiment asap.

What's the status on this?

I have implemented a test for the impact of the changes in issue55.py as 
requested by Gabi. It is currently waiting in the queue (issue55-EVERYTHING).

I implemented approach 3 in r4703 (but must confess that this lead to an ugly
piece of code). The other approaches are now a wish (issue111).

There are at least three different possible approaches:

 1. Compile away negative preconditions early (like FF).
 2. Introduce new derived variables, as described in the AIJ paper on the
    translator.
 3. Treat the negative precondition as a disjunctive precondition and
    expand it by "multiplying out" the possibilities.

Each approach has its pros and cons.

Approach 1. may be the most robust approach, but we'd have to check if it causes
us to suffer in cases that we care about that currently work fine.

Approach 2. is probably the worst one in general since most of our heuristics do
not supported derived predicates. It may be the best one for heuristics that do
properly support derived predicates, though.

Approach 3. may be the best one where you can get away with it, but it can be
exponential, and I'm not sure that we can rule out that we'll hit such
exponential cases in some of the weirder compiled problems that people come up
with. This is probably also the one that is easiest to implement.

Ultimately, we might want to introduce options for things like this, but for now
I'd go with approach 1 or 3, and once that is done open a new "wish" issue for
introducing an option.

This is definitively a problem with negative preconditions:

For example, operator block-15 stn-1-up stn-1-up-recv
becomes 
begin_operator
block-15 stn-1-up stn-1-up-recv
2
6 6
67 0
3
0 2 9 8
0 48 -1 1
0 50 -1 1
0
end_operator

where the precondition on variable 6 is the interesting thing:

var6:
  0: Atom queue-state-ctl(stn-1-up-recv)
  1: Atom queue-state-start(stn-1-up-recv)
  2: Atom queue-state-att(stn-1-up-recv)
  3: Atom queue-state-data(stn-1-up-recv)
  4: Atom queue-state-empty(stn-1-up-recv)
  5: Atom queue-state-stop(stn-1-up-recv)
  6: <none of those>

So the operator requires value "none of those, where es the original operator
only requires that some of the variable values are not true:

  (:action block-15
   :parameters (?s - station ?q - queue)
   :precondition (and (station-read-queue ?s ?q)
              (station-state-15 ?s)
              (not (queue-state-att ?q))
              (not (queue-state-start ?q))
              (may-pop ?q))
   :effect (and (not (station-state-15 ?s))
        (blocked ?s)
        (not (may-push-att ?q))
        (not (may-push-start ?q)))
   )

Since "none of those" is not reachable from the initial state, the operator gets
finally removed from the task rendering the task unsolvable.

Should we really compile away negative preconditions in general or should we
solve this locally?

Note to self: when dealing with the "negative precondition issue", some care
should be taken to deal with it properly in the case of static predicates, and
in particular the special "=" predicate.

For static predicates of large arity (blocked-trans or some such in
Airport-ADL?) that might occur negatively somewhere, we don't want to build a
huge set of initial state atoms.

Also for non-static predicates, we don't actually want to build negative
versions of the instantiations that don't occur in any ground operator... need
to think about this.

Maybe the best way to get rid of the negative precondition issue is to compile
negative conditions away.

We would need to special-case negation as failure (maybe only allow negative
preconditions within special negation as failure rules of the type "X := not
Y"?), but apart from that it shouldn't be too hard to get rid of negative
conditions everywhere.

The performance impact of that should be measured, but I doubt it's too bad --
most domains don't use negative conditions anyway, and the remaining ones are
either currently buggy, or any inefficient encoding issues should be handled by
invariant synthesis.

The attached problem, provided by Patrik, is solvable (see attached plan), but
A*/LM-cut thinks it is unsolvable. Patrik reports that using an alternative
formulation without negative preconditions works correctly, so this is probably
the old negative preconditions bug in the translator.