Great, thanks!

I ran experiments with the lama-2011 and the bjolp IPC configurations. There are
no changes at all with bjolp. With lama 2011, the new version is sometimes
better, sometimes worse. Overall it is slightly worse (1 fewer solved task,
which was solved close to the time limit). This looks like a random effect not
like a problem of the code.

Malte and Jendrik already reviewed the code so I merged this.

The experiments did not reveal any changes except for the landmark count
heuristic, especially with the Zhu-Givan landmark generation. I need to check
what's going on there.

Experiments are running. Hopefully they will have finished on Friday.

Since Erez, Malte and I prefer variant 1, let's go for it. Malte, I hijack the
issue...

I'm usually in favour in whatever leads to the cleanest interface, even if there
is some porting effort, so I'd be in favour of 1., unless we can benefit from
the prevail/pre/post representation in our own code.

This is kind of a duplicate but issue371 concentrates on the interface between
the preprocessor and the search whereas here the emphasis is on the search
itself. So we can handle the search part here. There are 2-3 options: 

1. Adapt all of our code base and remove the old precondition/prevail variant.
   This has the disadvantage that we break everyone else's code. The advantage
   is that we do force them to adapt their code and we do not need to support
   both variants.
2. Still support the old "interface" by internally creating the old 
   representation on demand. However, this could have a negative performance 
   impact for everyone using the old precondition/prevail variant. In this
   case, we should mark the old interface as deprecated.
3. Try to somehow offer both views in an efficient way.

What do you think?

Gabi, this may be a duplicate of something that is assigned to you (related to
"new translator output format" etc.)?

In that case, let's go for it

> I agree that it's probably not a lot of work - in theory.
> In practice - I'm not so sure. Once we start modifying code that hasn't
> seen the light of day in a while, undesirable things might happen.

The heuristic initialization code isn't rocket science. :-) This is all very
simple, very direct code. The tie-breaking beaviour of some of the heuristics is
a real concern, but that's why we're developing automated ways to test things
like that.

Regarding 1.0, there is no fixed deadline, just a (loosely defined) set of
outstanding issues.

I agree that it's probably not a lot of work - in theory.
In practice - I'm not so sure. Once we start modifying code that hasn't seen the 
light of day in a while, undesirable things might happen.
This means we would need to do A LOT of testing, and that will definitely take a 
lot of time.
By the way - when is the version 1.0 deadline?

It's not a big change in terms of these heuristics, as we already use the same
information -- we just store it in a stupid way. Again, it's *not* a semantic
change, just a much-needed change in interface.

Most of the heuristics you list already convert internally to a more standard
precondition/effect representation anyway. The only ones I can think of which do
make use of the prevail/precondition distinction are merge-and-shrink and the
two variations of causal graph heurisic (i.e. h^CG and h^cea). For those, it
might be a bit more work to code, but I don't think their behaviour should be
affected in any way, i.e., they should still compute the same h values, which
should be pretty easy to test.

It will need some performance testing for heuristics whose behaviour depends on
the order of preconditions, since the order of preconditions will change,
preferably to something canonical. Off the top of my hat, these should not be
affected/not affected in terms of the heuristic values that are computed:

 * not affected: merge-and-shrink, h^max, h^add, landmarks, h^CG, h^cea, blind
 * possibly affected: LM-cut (h^max tie-breaking), h^FF (best achiever
   tie-breaking)

(It is possible to implement it in a way that LM-cut and h^FF wouldn't be
affected either, by ordering the preconditions in the same way as currently. But
I think that'd be kind of stupid, since the point of this is to get rid of this
awkward anomaly in our representation.)

My preference is to get rid of this before 1.0, since this will be less overall
effort. (No need to document both the old and new file formats.) However, if it
turns out to be too much work, I have no problems with deferring this until
after 1.0. (I'd still call the version 1.0 -- after all, we're approaching 7
years of development time. :-))

So we would have two lists for each operator: applicability preconditions, and a 
list of conditional effects, and it would look something like this:

Operator A:
Preconditions (applicability): v1=1, v2=4, ...
Conditional Effects: [v3=4]:v3=5, []:v4=5, ...

Sounds like a good idea to me.

However, I took a quick look at the code, and found (at least) these need to be 
modified: merge and shrink, landmarks, relaxation heuristic, h^m heuristic

This will require a significant amount of code modification, and lots and lots 
of testing, so I vote we should wait with this.

Maybe call the upcoming release 0.9, and after making this modification call it 
1.0?

This change will require some work to be done on heuristics (mine at least), but
I think it is necessary. As far as I see there are several pros:
1. it will better fit Malte's definition of MPT,
2. there will be no option of defining 2 conditional effects on the same
variable with conflicting pre,
3. it seems more logical to outsiders.
Anyone can think of any cons, except for the code change?

I think I know what you mean. Currently, the precondition in a (cond, pre, eff)
triple are to be treated exactly as prevail conditions, i.e., they have nothing
to do with the listed conditions, but are global applicability conditions of the
operator. For example, consider this operator:

PREVAIL: [a = 1, b = 2]
EFFECTS: [(COND: [], VAR: c, PRE: 3, POST: 4),
          (COND: d = 1, e = 2, VAR: f, PRE: 3, POST: 4)]

According to our semantics, this means that the operator is applicable iff a=1,
b=2, c=3 and f=3. It will always set c to 4, and if d = 1 and e = 2, it will
also set f to 4.

This is not complicated as such, but it is confusing/misleading: most people who
first see the notation assume that f=3 is not an absolute precondition but
related to the conditions of that effect, but that's not the case.

Indeed, that's one of the reasons why we should remove these preconditions
inside effect triples. The reason why I opened the discussion was that I had a
discussion about exactly this topic today with Thomas (who was surprised by the
semantics).

I mean definition-wise.
I don't remember exactly, but Michael had some questions, so I'll nosy him.

What do you mean with tricky issues with conditional effects?

Sorry, misread your comment. :-)

I think that this is a major change, which would affect (at least) every 
heuristic, so it's probably not a good idea to do this before 1.0.

I also think that we need to think very carefully about how to do this, since 
there are some very tricky issues when conditional effects are involved.

Ever since we added conditional effects for IPC 2004, it's become tedious to
handle both "prevail conditions" and "preconditions" everywhere, so I think
these should be unified in the data structures and output files. If useful, we
could provide query methods to the Operator class that can distinguish these on
the fly for those (few) cases where the distinction is useful.

This doesn't have to be done any time soon, although if we want to document the
translator format for external parties, it might be better to do this before 1.0
so that we have a more stable format. What do you think?

I've not yet nominated it to 1.0, but feel free to nominate it if you want to.