Title support derived predicates properly in our heuristics
Priority feature Status chatting
Superseder Nosy List erez, malte
Assigned To Keywords
Optional summary

Created on 2010-08-02.00:54:16 by malte, last changed by malte.

msg1407 (view) Author: malte Date: 2011-06-30.10:42:57
Thanks for bringing this to my attention, Erez! The comments in msg898 still
apply, so I renamed the issue to better reflect what needs to be done and
removed the 1.0 keyword.
msg1401 (view) Author: erez Date: 2011-06-30.08:37:22
I think this is also resolved (but I'll let Malte close this one).
msg898 (view) Author: malte Date: 2010-12-18.00:24:03
One thing we should *really* look into is how derived predicates are treated by
our heuristics that support them.

In particular, I think at least one of our implementations at one point simply
treated axioms are zero-cost operators. That means that if an axiom is currently
true [*] and has to be false [*] in the goal or for some precondition, we'll get
h = infinity since there's no explicit rule that sets axioms to false (they are
only false "by default" if none of the rules triggers, never set to false by an
explicit rule*).

This is essentially the reason why we have "extended domain transition graphs"
(see JAIR paper on Fast Downward) although I'm not sure if and where they're
currently computed and used.

[*] "true" and "false" in the sense of "proved by a derivation rule" and "no
rule applied" -- in the code, "true" might actually correspond to "0" and
"false" to "1". Not sure.
msg896 (view) Author: malte Date: 2010-12-18.00:15:59
The "conditional effects in FF heuristic" issue is now separate: issue166
msg381 (view) Author: malte Date: 2010-08-02.00:54:16
Some of our heuristics (e.g. h^FF) purport to support conditional effects and
derived predicates, but the support is somewhat strange. For example, if I
recall correctly, our h^FF does not actually generate proper relaxed plans on
tasks with conditional effects because each action is only counted once (but
might be required multiple times). Similarly, support for derived predicates,
where they are accepted at all, is shaky.

In the long term, this should be fixed. For version 1.0, this should at least be
documented properly -- including a warning at runtime, maybe even a required
option that says "I'm aware of these limitations, let me use these heuristics on
these problems regardless".
Date User Action Args
2011-06-30 10:42:57maltesetmessages: + msg1407
keyword: - 1.0
title: document limitations w.r.t. conditional effects and derived predicates -> support derived predicates properly in our heuristics
2011-06-30 08:37:22erezsetnosy: + erez
messages: + msg1401
2010-12-18 00:24:03maltesetmessages: + msg898
2010-12-18 00:16:00maltesetmessages: + msg896
2010-08-02 00:54:16maltecreate