Issue497

Title Canonicalize the order of effects, conditions, mutexes, etc.
Priority wish Status chatting
Superseder Nosy List florian, gabi, jendrik, malte
Assigned To Keywords
Optional summary
Also consider issue371.

When this is addressed, the canonicalization (sorting and uniquing
preconditions) in RelaxationHeuristic can be removed. (See comment there
pointing to this issue.)

Created on 2014-12-10.11:03:45 by gabi, last changed by malte.

Summary
Also consider issue371.

When this is addressed, the canonicalization (sorting and uniquing
preconditions) in RelaxationHeuristic can be removed. (See comment there
pointing to this issue.)
Messages
msg7568 (view) Author: malte Date: 2018-09-19.14:02:35
As a note, we currently have operators with duplicate preconditions. See msg7567
in issue814.
msg4817 (view) Author: gabi Date: 2015-11-20.16:46:35
We just discussed this in the developer meeting. Our idea would be that the
input of the search component should be canonical. Abstract tasks do not have to
preserve this, but have to provide a mechanism to provide a canonical version of
itself on demand. If some piece of code depends on a canonical representation
(e.g. because this allows for a more efficient implementation), it would
explicitly ask the abstract task for such a representation.

An abstract task that is already canonical (e.g. a cost transformation of the
root task) would just return itself. Otherwise, it can create an explicit
canonical representation of itself. To avoid unnecessary explicit tasks, an
abstract task should have a method "is_canonical()" (or similar). If there are
nested abstract tasks, it is then for example possible to only explicitly
represent the final (outermost) task.

If someone starts working on this issue, it would in my opinion be perfectly
fine to split the issue into a part for the translator/preprocessor and one or
several parts for the search component.
msg4816 (view) Author: gabi Date: 2015-11-20.15:17:16
In issue371 Malte brought up the question, whether it really makes sense to
canonicalize the order of everything in the translator output if we do not also
enforce such an order in abstract tasks in the search component.

I re-set the state of this issue to chatting because this is something we
probably want to discuss among a wider group of developers first.
msg3902 (view) Author: gabi Date: 2014-12-10.11:03:44
Split off meta issue371

We should require that all preconditions, effect conditions, mutexes etc. are
sorted. Much of this is canonicalized already, and some of the code requires it
for correctness, but since this isn't prescribed anywhere, we have lots of
assertions that check the canonicity all over again in all kinds of places.
History
Date User Action Args
2018-09-19 14:02:39maltesetsummary: Also consider issue371. When this is addressed, the canonicalization (sorting and uniquing preconditions) in RelaxationHeuristic can be removed. (See comment there pointing to this issue.)
2018-09-19 14:02:35maltesetmessages: + msg7568
2015-11-20 16:46:35gabisetmessages: + msg4817
2015-11-20 15:17:16gabisetstatus: in-progress -> chatting
assignedto: gabi ->
messages: + msg4816
2014-12-10 11:03:45gabicreate