Message4836

Author silvan
Recipients malte, silvan
Date 2015-11-26.13:27:56
Content
A few new action items from an old email:

M. heuristic representation:
  - The class that is currently called HeuristicRepresentation doesn't
  represent the heuristic. It represents the abstraction. Suggestion:
  rename it to MergeAndShrinkRepresentation, which is the name we use
  in our ICAPS 2015 paper.
  - We currently have a two-stage heuristic lookup process: map the
  concrete state to an abstract state, then map the abstract state to
  a cost value. The second step is unnecessary since we might as well
  write the cost value directly into the table of the MSR's root node
  (both costs and abstract states are represented by the same type).

N. distances:
  - Distances computation could be made more fine-grained. Which things
    do we really need to recompute after shrinking? When do we need g
    values, and when don't we? It might be a good idea to give the
    shrink strategies and merge strategies a methods that let them tell
    the overall algorithm whether they are interested in g values and/or
    h values; e.g., only shrink_fh would be interested in g values;
    merge_dfp is interested in h values; shrink_bisimulation is
    interested in h values when using greedy bisimulation or when using
    h for initialization (which at the moment we always use?).
  - Should we make pruning irrelevant and/or unreachable states
    configurable? Should it be a *separate* step that is controlled by
    the main merge-and-shrink loop? (Logically, it is a separate
    transformation of the factored transition system. In practice, it
    might be more efficient to couple it with other steps.)
  - The vector<bool> of prunable states should probably be accessed the
    same way as the g and h values, rather than using a separate
    interface as it is done currently (g and h are stored in the
    Distance object and requested individually; prunability is returned
    as a complete vector).

O. FTSFactory
  - We currently have a two-stage initialization for the atomic
    transition systems. First, they are created in an incomplete state,
    and then the factory takes over the rest of the initialization. We
    should have a constructor that generates them in one shot.
History
Date User Action Args
2015-11-26 13:27:56silvansetmessageid: <1448540876.34.0.601077093461.issue567@unibas.ch>
2015-11-26 13:27:56silvansetrecipients: + silvan, malte
2015-11-26 13:27:56silvanlinkissue567 messages
2015-11-26 13:27:56silvancreate