changes in alternation search for issue206

[Malte, 2011-01-16 17:35:36]

Hi Gabi,

here's an aspect of the fix for issue206 that I would like you to have a look
at.

Cheers,

Malte

http://codereview.appspot.com/4045041/diff/1/src/search/open_lists/alternatio...
File src/search/open_lists/alternation_open_list.cc (right):

http://codereview.appspot.com/4045041/diff/1/src/search/open_lists/alternatio...
src/search/open_lists/alternation_open_list.cc:71: new_entries +=
open_lists[i]->insert(entry);
I added the dead-end check here so that if open list i considers this state as a
dead end, it won't be added to that open list. But I'm not confident that
is_dead_end() will always think about the correct state here, i.e., that it will
be in the right context. Is this assured? If yes, why?

[Gabi, 2011-01-17 14:32:53]

http://codereview.appspot.com/4045041/diff/1/src/search/open_lists/alternatio...
File src/search/open_lists/alternation_open_list.cc (right):

http://codereview.appspot.com/4045041/diff/1/src/search/open_lists/alternatio...
src/search/open_lists/alternation_open_list.cc:71: new_entries +=
open_lists[i]->insert(entry);
On 2011/01/16 17:35:37, Malte wrote:
> I added the dead-end check here so that if open list i considers this state as
a
> dead end, it won't be added to that open list. 

The original idea is that the sub-openlists ignore the insert request when they
regard the node as dead end. The simple open lists actually do this but for
example Pareto and Tiebreaking do not implement this as intended.

> But I'm not confident that
> is_dead_end() will always think about the correct state here, i.e., that it
will
> be in the right context. Is this assured? If yes, why?

This must be ensured by the search algorithm by calling evaluate with the
correct state (directly) before. We definitely should think more concretely
about something like an evaluation context to ensure this.