Title Use new task interface in h^max, ipc max, and goal count heuristics
Priority feature Status resolved
Superseder Nosy List florian, jendrik, malte, manuel, thomas
Assigned To thomas Keywords
Optional summary

Created on 2015-07-15.11:54:13 by florian, last changed by jendrik.

msg4734 (view) Author: jendrik Date: 2015-11-04.17:25:24
The code has been merged. Therefore, I'm closing this issue.
msg4703 (view) Author: malte Date: 2015-10-29.14:41:51
None from me.
msg4701 (view) Author: jendrik Date: 2015-10-29.14:04:17
I added a note in issue348 for the convert_global_state problem. 

I guess there are no obstacles to merging this, right?
msg4700 (view) Author: malte Date: 2015-10-29.12:37:12
Thanks! There are two possible sources for the slowdown:

1. the call to convert_state
2. the overhead associated with iteration over the var/val pairs in the goals proxy.

Point 2. might produce some measurable overhead over the old code and could be
reduced by "precomputing" this information, i.e., storing it in instance
variables once during initialization. But I think this is a micro-optimization,
and I don't think it's worth it. In any case, it's clear that 1. dominates the
runtime, and any slowdown we are seeing is caused by this. (That is, even if 2.
were worthwhile, we could not really measure this without addressing the more
import 1. first.)

If I recall correctly, allowing smarter ways of dealing with heuristics that
only need to look at a small subset of the state variables is already on our
radar. Before we do that, we won't get a significant speed-up for the goal-count
heuristic. So I suggest to consider the goal-count heuristic done. If we already
have an issue open for getting rid of the need to always convert the whole
state, then it might sense to mention the goal-count heuristic there as
something to test.
msg4699 (view) Author: thomas Date: 2015-10-29.12:30:18
msg4698 (view) Author: malte Date: 2015-10-29.12:26:14
Do we have a link to a diff (or pull request) somewhere? From what I expect the
code for the goal count heuristic to look like, it's probably not worth looking
at the runtimes in much detail.
msg4697 (view) Author: florian Date: 2015-10-29.12:22:46
Looks like h^max actually is faster now, but goal count got a bit slower (not
much but consistently). You could add relative scatter plots to see the details
of that. To do so, copy the file for example from
experiments/issue582 and then add the following lines to the experiment:

from relativescatter import RelativeScatterPlotReport

        get_category=lambda run1, run2: run1.get("domain"),

        get_category=lambda run1, run2: run1.get("domain"),
msg4696 (view) Author: thomas Date: 2015-10-29.12:12:40
To me, the results look pretty much identical:
msg4372 (view) Author: florian Date: 2015-07-15.11:54:13
All these heuristics should use the task it get from the options object (as a
TaskProxy) instead of the global task. We can handle them in one issue because
the changes required for each one should be minor.
Date User Action Args
2015-11-04 17:25:24jendriksetstatus: in-progress -> resolved
messages: + msg4734
2015-10-29 14:41:51maltesetmessages: + msg4703
2015-10-29 14:04:17jendriksetmessages: + msg4701
2015-10-29 12:37:12maltesetmessages: + msg4700
2015-10-29 12:30:19thomassetmessages: + msg4699
2015-10-29 12:26:14maltesetmessages: + msg4698
2015-10-29 12:22:46floriansetmessages: + msg4697
2015-10-29 12:12:40thomassetmessages: + msg4696
2015-10-27 09:49:55manuelsetassignedto: manuel -> thomas
nosy: + thomas
2015-10-27 09:27:10manuelsetstatus: unread -> in-progress
nosy: + manuel
assignedto: manuel
2015-07-15 17:16:56jendriksetnosy: + jendrik
2015-07-15 11:54:13floriancreate