Fair 'nough. Every heuristic and search procedure that builds things once prior to 
search needs a custom mechanism to "reset" if one wants to do it efficiently, and 
I understand it's a fairly major ask. I've been more than thrilled with the direct 
support from the FD team on the few touch-points I need to make it a reality. 
Thanks!

Hi Christian (and others), we're marking this as closed for now.

These days we try to avoid keeping "wish" issues open indefinitely when there is no concrete implementation plan. This doesn't mean that these kinds of features aren't something we would like to support, and our current work towards a library interface for Fast Downward goes into supporting use cases like these better. But the level of granularity of this wishlist item is not one we can work on actively. (Plus, we would need someone to commit to spending time on this.)

> Any timeline for the next round of major changes?

Hard to predict.

I expect issue461 to go forward soon, but this will just require mindless
renaming. This is in preparation for issue439, which will initially only be used
for a few heuristics and should not require more than a few days of work to
complete, I hope, but given the upcoming deadlines I wouldn't be surprised for
it to take until some time in October or longer to get this work in. Once this
is merged, we'll probably be busy converting other parts of the planner to the
new interface, which will likely require weeding out some kinks in the interface
and can again be disruptive.

It may be a good strategy not to follow all these developments for a while and
simply fork off until after the ICAPS deadline. We may be going on a somewhat
circuitous route.

Aye, makes perfect sense (original name was just one proposal for a problem that 
needs solving). Any timeline for the next round of major changes? Just want to 
schedule my time properly for the next round of merging.

Thanks, this was helpful! We have some structural changes undergoing (sorry for
the disruption, but on the positive side I think things will be much cleaner
afterwards), and once things have stabilized a bit, I think we should revisit this.

I'm still not a big fan of modifying the SearchEngine/Heuristic protocol, but I
hope we should be able to support this interface cleanly eventually. I think
it's better to wait with this until the dust has settled, though; there are some
correlated issues here.

I've renamed the issue to be more reflective of the use cases we want to enable
and less of how to support them. Do you agree with the goal in the new name, or
does it not cover your use cases?

So if you check out the 3 links I posted, they cover my personal use case of needing a 
reset (I invoke the solver repeatedly in PRP with new initial states and goal states). I 
only use one engine (LazySearch) and one heuristic (additive or ff...forget which, but 
both inherit from RelaxationHeuristic). Summary of what I had to do:

http://goo.gl/iVrO48 (SearchEngine::reset())
http://goo.gl/6utn9L (LazySearch::reset())
- Not much savings here, but required to reset the data structures and pass on the reset() 
invocation to all the heuristics. Plus, I think I had an issue deleting / recreating the 
engine from scratch if I recall correctly...


http://goo.gl/bH6P55 (RelaxationHeuristic::reset())
- This was the important shift. If you scroll just a little further, you see what needs to 
occur for initializing any relaxation heuristic (building the props, creating the unary 
ops, and until recently simplifying the unary ops). The reset method instead just needs to 
deal with the current goal -- comparatively a much easier process in a domain with many 
ground actions.

----

Another possible need for resetting may be EHC techniques. I can imagine wanting to 
recompute all the landmarks or whatever after I've committed to jumping to a particular 
state. Come to think of it, there seems to be a dual notion that may be worth considering 
-- informing a heuristic that there's a new goal -vs- informing the heuristic that there's 
a new initial state. Some (e.g., relaxation based ones) only care about new goals, while 
others (e.g., landmark based ones) would care about new goals or new initial states. Maybe 
a subscriber model for the heuristics would work, and then warnings / errors thrown when 
the user tries to use a heuristic that isn't capable of handling a newGoal or newInit 
signal?

I once had a reset method for heuristics, which I used to clear the (multi-)path 
dependent landmarks heuristic. I needed that because selective max did its 
initial sample using the heuristic (the same object), but I then wanted to have 
the heuristic start with a clean slate (otherwise, all sorts of assertions are 
violates).

I do agree with Malte that encapsulating the heavy, reusable part of the 
initialization would be good. However, we should first list a few different 
cases where we would want to "reset" a heuristic, and see exactly what needs to 
be reset.

Not sure I like it; this is perhaps something I'd prefer to see maintained as an
independent patch, because knowing when a heuristic can and should be safely
reset (considering that it can be used in many different searches in an iterated
search) and how to do this is not trivial. Of all structural changes, the ones I
like least are the ones that are intended to make immutable objects mutable or
turn a one-pass lifetime into something that sticks around indefinitely. I think
object lifetimes are the hardest thing to reason about in a complex codebase, so
that's something I'd really like to keep straightforward.

Search engines should already be light-weight to construct, so let's talk about
heuristics. I'm not sure we really have any heuristics that are at the same time
expensive to construct *and* would benefit from such a reset function in case of
a changing goal. (The expensive precomputation tends to be goal-specific.) With
changing initial state, I think it's already the case that the heuristics can be
reused unless they are path-dependent. (And the path-dependent ones need to be
recreated from scratch with changing initial states in any case.)

Can you given an example or two of a heuristic/search engine for which this is
useful?

Maybe we can support the same use case with a different design: encapsulate the
heavy, reusable part of the initialization in a different object, and make
lightweight heuristic objects that can be created/deleted quickly and reuse the
heavy object.

When modifying the FD planner to be invoked repeatedly for new initial states or 
goal states, it can be costly to destroy / recreate the search engine and 
associated heuristics. If the action set doesn't change, a "reset" method could 
save quite a bit of time by only changing what is required. This is the current 
approach for the FOND planner PRP, but it is only implemented for the one search 
engine and heuristic used internally:

- http://goo.gl/iVrO48
- http://goo.gl/6utn9L
- http://goo.gl/bH6P55