Message1397

Author malte
Recipients emilkeyder, erez, malte, rpgoldman, silvia
Date 2011-06-29.22:01:34
Content
Ah, I think you brought us on the right track here!

Our documentation on
http://www.fast-downward.org/HeuristicSpecification#Landmark_count_heuristic
says: "conditional effects: supported if admissible=false". I know Silvia
evaluated LAMA on tasks with conditional effects. However, I guess this support
is only there for the parts that Silvia implemented, not for lm_hm.

Silvia, is lm_zg supposed to support conditional effects?


It's fine to not support them in parts of the code, but in such cases we should
bail out with an error message rather than silently ignoring them; see
MergeAndShrinkHeuristic::verify_no_axioms_no_cond_effects in
raz_mas_heuristic.cc for an example. (Really, this function should be available
globally, rather than being stuck in this place.)

So one thing we can do is document that only some LM generation methods support
conditional effects and let the others reject tasks that have them.

Of course, we could also open a separate issue to add such support, which should
not be too hard (famous last words?). Anyone interested in looking into that? I
can give advice, but probably won't be able to provide code.


Conditional effects are probably only part of the story here, though.
The main problem for LM_RHW here are vey likely derived variables, which the
translator introduces in this case (I guess because of universally quantified
conditions in the original input).

Our documentation says "axioms: supported if admissible=false (but may behave
stupidly and be unsafe)", where "unsafe" means: can falsely claim a problem to
be unsolvable. So the outcome we get here might just be a known limitation
rather than an actual bug. One potential bug is that an alternation search that
uses both safe and unsafe heuristic should be safe; I think it isn't in this
case because the LM-count heuristic doesn't own up to being unsafe. But that
should be easy to fix and address the actual problem here.


In summary:

1) lm_hm should probably bail out when faced with conditional effects or axioms,
or at least print a clear warning message, also on cerr, that it is unsafe in
this case (like the one for issue240). It should not fail an assertion.

2) Optionally, we should open an issue for adding conditional effect support to h^m.

3) We might also open an issue for proper derived predicate support for all LM
generation methods.

4) We should clarify what the exact support for conditional effects for LM
heuristics is in the documentation.

5) The LM count heuristic should only claim that it is safe for those tasks
where this is actually true.
History
Date User Action Args
2011-06-29 22:01:35maltesetmessageid: <1309377695.65.0.177501465394.issue247@gmail.com>
2011-06-29 22:01:35maltesetrecipients: + malte, erez, silvia, emilkeyder, rpgoldman
2011-06-29 22:01:35maltelinkissue247 messages
2011-06-29 22:01:34maltecreate