Issue442

Title lm_rhw detects wrong gn-orderings with derived predicates
Priority bug Status chatting
Superseder Nosy List clemens, erez, gabi, malte, salome, silvan
Assigned To Keywords
Optional summary
We expect this to be resolved when issue247 is resolved.

Created on 2014-07-23.14:22:26 by salome, last changed by malte.

Summary
We expect this to be resolved when issue247 is resolved.
Messages
msg11102 (view) Author: malte Date: 2023-07-05.15:57:26
Keeping both active is fine if you think it makes sense. But then we should identify one issue as the primary one in which we're planning to track and fix the problem. From what you write it sounds like this should be issue247.

We usually do cross-referencing both ways prominently in the summary, so that we're less likely to forget resolving the subordinate issue when the primary one gets resolved. I've updated the summary here and will update the other issue next.
msg11101 (view) Author: clemens Date: 2023-07-05.15:53:21
Adding a reference to issue247 where we identified exactly these orderings as the source claiming solvable problems unsolvable. There's a more thorough discussion of our findings so far and possible solutions. We could consider closing this issue in an attempt to clean up the issue tracker, but I don't mind keeping both issues active as a reminder that we should do something about this.
msg3218 (view) Author: salome Date: 2014-07-23.14:22:26
If two landmarks are derived predicates and one derived predicate is dependent
on the other one, lm_rhw can detect a greedy-necessary ordering between them,
even if they first become true in the same state (since the second one is
derived from the first one). For example this happens with the following derived
predicate from the psr-large domain (where unsafe is also a derived predicate):

  (:derived (affected ?x - DEVICE)
        (and (breaker ?x)
             (exists (?sx - SIDE) (unsafe ?x ?sx))))

I think the example would even work if unsafe were not a derived predicate; the
problem is rather that the greedy-necessary ordering is detected over possible
achievers which can also be axioms:

The lm_rhw code (landmark_factory_rpg_sasp) detects landmarks with greedy
necessary orderings over shared preconditions of possible achievers, and
considers "actual" operators as well as axioms when getting all possible
achievers. While this is ok for finding new landmarks; when detecting orderings
we would need to distinguish between actual operators and axioms.
History
Date User Action Args
2023-07-05 15:57:26maltesetmessages: + msg11102
summary: We expect this to be resolved when issue247 is resolved.
2023-07-05 15:53:21clemenssetnosy: + clemens
messages: + msg11101
2014-07-23 16:02:48erezsetnosy: + erez
2014-07-23 14:36:45maltesetnosy: + malte
2014-07-23 14:22:26salomecreate