Issue499

Title POR integration
Priority feature Status resolved
Superseder Nosy List florian, jendrik, malte, martin
Assigned To martin Keywords
Optional summary

Created on 2014-12-12.15:37:16 by martin, last changed by martin.

Messages
msg5149 (view) Author: martin Date: 2016-01-26.12:04:23
We have merged this issue. There is follow-up work in issue628 and issue629.
msg5147 (view) Author: malte Date: 2016-01-22.17:37:07
I briefly looked at the code changes that affect the core (i.e., everything that
cannot be disabled) and made a few comments. I'm happy not to look at the rest. :-)
msg5145 (view) Author: florian Date: 2016-01-22.17:30:35
I was asking Martin, since I already talked to you about it. But if you want to
have another look, we could also delay the merge until next week.
msg5144 (view) Author: malte Date: 2016-01-22.17:19:31
Whom are you asking?
msg5143 (view) Author: florian Date: 2016-01-22.16:56:46
Can we merge it, then?
msg5142 (view) Author: martin Date: 2016-01-22.13:52:09
A* + LM-cut on the newest version in the por issue branch compared to A* +
LM-cut on the last version from default shows that the time and number of
expansions have remained the same (see below).

http://ai.cs.unibas.ch/_tmp_files/mwehrle/issue499-v1-issue499-base-issue499-v1-compare.html

(The version f4e72a652f92 which is compared to in msg5131 is much older.)
msg5131 (view) Author: martin Date: 2016-01-21.17:14:58
The sum of expansions until the last jump indeed has increased in most domains.

http://ai.cs.unibas.ch/_tmp_files/mwehrle/comparison-lmcut.html
http://ai.cs.unibas.ch/_tmp_files/mwehrle/comparison-lmcut-stubborn-sets-simple.html
http://ai.cs.unibas.ch/_tmp_files/mwehrle/comparison-lmcut-stubborn-sets-ec.html
msg5130 (view) Author: florian Date: 2016-01-21.17:04:24
I'm confused that the number of expansions is different for the two versions of
LM-cut. Does this include a change of the operator ordering? Can you include the
expansions until last jump in the report to make sure this is not only on the
last f-layer?
msg5129 (view) Author: martin Date: 2016-01-21.16:37:34
Regarding Malte's question in msg5127: A'>=A in all domains, B'>=B in all but a
few domains.

http://ai.cs.unibas.ch/_tmp_files/mwehrle/comparison-lmcut.html
http://ai.cs.unibas.ch/_tmp_files/mwehrle/comparison-lmcut-stubborn-sets-simple.html
http://ai.cs.unibas.ch/_tmp_files/mwehrle/comparison-lmcut-stubborn-sets-ec.html

f4e72a652f92 refers to the old version, 69f9b2915ed9 to the current version. 

The current version is additionally evaluated on the movie and storage domains,
so the overall coverage values need to be interpreted accordingly. For
stubborn-sets-ec, the old version contains the "active operators" flag in the
config-nick, which is included by default in the new version.
msg5128 (view) Author: florian Date: 2016-01-21.15:14:58
This is unrelated to Malte's commment because I wrote this before reading msg5127.

It seems like only the simple stubborn sets method was affected by the changes.
If we want to look into this later, we should start looking there.
msg5127 (view) Author: malte Date: 2016-01-21.15:09:18
I have a question regarding performance.

Let A be coverage of the old version without using POR and B be the coverage of
the old version with POR.

Let A' be the coverage of the current version without using POR and B' be the
coverage of the current version with POR.

If I understand you correctly, B' - A' is lower than B - A. If the reason for
this is that we speeded things up in general, that's fine. Can we make a
plausibility check of this? If this explanation is correct, we should have A' >
A and B' > B. Is this true in general, in all domains, in all but a few domains?
msg5126 (view) Author: martin Date: 2016-01-21.14:46:05
Renaming is done. 

The coverage increase gained by the POR methods is not as high as previously
reported, presumably because the base version of Fast Downward has become more
efficient. Recent refactoring also caused a slight coverage decrease, see below
for experimental results (Jan 10 compared to Jan 20). 

http://ai.cs.unibas.ch/_tmp_files/mwehrle/e10-01-2016-por-integration-report-abs-d.html
http://ai.cs.unibas.ch/_tmp_files/mwehrle/e20-01-2016-por-integration-report-abs-d.html

Still this seems ok to be merged now, as we can have a closer look at the
efficiency later on.
msg5084 (view) Author: malte Date: 2016-01-13.19:50:32
I have one general suggestion: I wouldn't call it "por" and
"PartialOrderReductionMethod" etc.

What the interface allows us is to prune successors, and possibly to reorder
them. (We haven't discussed the reordering part yet, but the reordering options
we have in one of our search algorithm could also very well be done here.)

Not all pruning methods are POR. For example, we could move the pruning based on
g bounds into a pruning method (which would have the advantage of being more
nicely composable), or we could do random pruning as in some search algorithms,
or we could perform dominance pruning, which is not partial-order reduction.

So I suggest to use a more general name like "PruningMethod" and directory name
"pruning" to reflect the more general purpose. (This name doesn't capture the
fact that this could also be used for reordering, but I don't have a good
suggestion for that.)
msg5083 (view) Author: florian Date: 2016-01-13.19:12:47
From my point of view this is ok to merge now. Malte, you recently said you
wanted to have a look at the changes in existing classes before we merge.

The changes are on Bitbucket:
https://bitbucket.org/mwehrle/por-integration/pull-requests/1/issue499

The following existing files have changes:
src/search/DownwardFiles.cmake (CMake plugin definition)
src/search/abstract_task.h (the Fact class for issue621)
src/search/options/option_parser.cc (help output)
src/search/search_engines/eager_search.cc
src/search/search_engines/eager_search.h
msg3917 (view) Author: martin Date: 2014-12-12.15:37:15
Considers the integration of two POR techniques for planning which have shown
best performance: simple stubborn sets (corresponding to the FD/forward
ordering) and SSS_expansion_core (which dominates expansion core), including
mutex-based interference.
History
Date User Action Args
2016-01-26 12:04:23martinsetstatus: chatting -> resolved
priority: wish -> feature
messages: + msg5149
2016-01-22 17:37:07maltesetmessages: + msg5147
2016-01-22 17:30:35floriansetmessages: + msg5145
2016-01-22 17:19:31maltesetmessages: + msg5144
2016-01-22 16:56:46floriansetmessages: + msg5143
2016-01-22 13:52:09martinsetmessages: + msg5142
2016-01-21 17:14:58martinsetmessages: + msg5131
2016-01-21 17:04:25floriansetmessages: + msg5130
2016-01-21 16:37:34martinsetmessages: + msg5129
2016-01-21 15:14:58floriansetmessages: + msg5128
2016-01-21 15:09:18maltesetmessages: + msg5127
2016-01-21 14:46:05martinsetmessages: + msg5126
summary: Renaming is done. The coverage increase gained by the POR methods is not as high as previously reported, presumably because the base version of Fast Downward has become more efficient. Recent refactoring also caused a slight coverage decrease, see below for experimental results (Jan 10 compared to Jan 20). http://ai.cs.unibas.ch/_tmp_files/mwehrle/e10-01-2016-por-integration-report-abs-d.html http://ai.cs.unibas.ch/_tmp_files/mwehrle/e20-01-2016-por-integration-report-abs-d.html Still this seems ok to be merged now, as we can have a closer look at the efficiency later on. ->
2016-01-21 14:12:15martinsetsummary: Renaming is done. The coverage increase gained by the POR methods is not as high as previously reported, presumably because the base version of Fast Downward has become more efficient. Recent refactoring also caused a slight coverage decrease, see below for experimental results (Jan 10 compared to Jan 20). http://ai.cs.unibas.ch/_tmp_files/mwehrle/e10-01-2016-por-integration-report-abs-d.html http://ai.cs.unibas.ch/_tmp_files/mwehrle/e20-01-2016-por-integration-report-abs-d.html Still this seems ok to be merged now, as we can have a closer look at the efficiency later on.
2016-01-13 19:50:32maltesetmessages: + msg5084
2016-01-13 19:12:47floriansetstatus: unread -> chatting
messages: + msg5083
2016-01-11 21:30:33jendriksetnosy: + jendrik
2015-12-09 17:40:16floriansetnosy: + florian
2014-12-12 15:37:16martincreate