Issue301

Title m&s bisimulation: always separate goal states from non-goal states
Priority feature Status resolved
Superseder Nosy List joerg, malte, mkatz, raznis
Assigned To malte Keywords
Optional summary

Created on 2011-11-17.14:14:20 by malte, last changed by malte.

Messages
msg1975 (view) Author: malte Date: 2011-11-21.19:26:43
Domain summaries:
http://www.informatik.uni-freiburg.de/~helmert/exp-issue301-eval-abs-d.html

Detailed results:
http://www.informatik.uni-freiburg.de/~helmert/exp-issue301-eval-abs-p.html

I compared overall coverage to the data from issue279 and it looks very similar.
Note that this is only for one merge strategy as opposed to the three different
ones we considered there, and that the bug was more likely to strike with the
other merge strategies, so the data is a little bit incomplete. Having said
that, we see that coverage is very similar to before and I verified the
following invariants for the non-greedy bisimulation configuration
(mas-bisim-false-rl):

- For all solved tasks, init_h == cost
- For all solved tasks, length + 1 == expansions *except* possibly for tasks
that include 0-cost actions

Marking this as resolved. If you're not happy with the conclusions, feel free to
reopen.
msg1969 (view) Author: malte Date: 2011-11-17.18:00:16
Reminder to self: Once the results for this are in, they should be compared to
the results of issue279.
msg1968 (view) Author: malte Date: 2011-11-17.17:56:40
PS: With these changes, the only difference between the "Bisim" and "DFP"
configs are in the "max_states" and "threshold" parameters: Bisim has no size
limit (max_states=infinity) and always performs bisimulation (threshold=1),
while DFP-N has a size limit and only performs bisimulation once that limit is
exceeded (max_states=threshold=N). All other, more accidental differences are
gone, which is great. Now let's hope that the experimental results turn out alright.
msg1967 (view) Author: malte Date: 2011-11-17.17:44:49
OK, pushed something, but didn't merge it to default yet -- since this changes
sensitive parts of the code, I want to run a test first. (You can get a preview
by looking at the issue301 branch.)

As discussed by email, there are some option changes:

- The initialize_by_h option is now gone, since the "false" value didn't work
  properly and it making it work properly seems to have a poor cost/benefit
  ratio. We always initialize by h *and* goal status now.
- For the "at_limit" option, only the two "simple" values "return" and "use_up"
  are left. The others behaved very similarly to "return" but had vastly higher
  code complexity. (See issue271.) The new default value is "return".
msg1966 (view) Author: malte Date: 2011-11-17.14:14:20
ShrinkBisimulation currently doesn't separate non-goal states from goal states
during initialization with the initialize_by_h=true setting. This should be fixed.

This is only an issue for tasks with zero-cost actions. (If there are no
zero-cost actions, h=0 is necessary and sufficient for being an abstact goal state.)
History
Date User Action Args
2011-11-23 01:14:58maltesetstatus: chatting -> resolved
2011-11-21 19:26:43maltesetmessages: + msg1975
2011-11-17 18:00:16maltesetmessages: + msg1969
2011-11-17 17:56:41maltesetmessages: + msg1968
2011-11-17 17:44:49maltesetmessages: + msg1967
2011-11-17 14:14:20maltecreate