I changed the open list to use state_var_t* instead of complete states.
I also added an option to choose whether to use cost/depth for the BFS.
There is no command line argument for this yet, we are running out of letters.

AFAIK, Gabi has made great progress on the command-line thing, but she can tell
you more.

All for the lack of a good *. 
I meant to put pointer in the open list, I will change it to State * on Sunday.
I'll also make the g/depth thing a parameter, but we should probably start working 
on the general command line parameter thing, we already have alphabet soup.

We looked at the cost vs depth issue with EHC + the RPG heuristic in Marvin
(ignoring macro-actions, so roughly equivalent to FF).  As you guessed, it's a
trade-off.  Taking the g value into account is generally quicker - sometimes
dramatically so.  But, ignoring it and considering only depth does lead to
slightly better plans.  We left it as a flag, with the default being to use
g-values as IPC2004 was all about speed, and it came out ahead.

(An option we didn't consider would be to use g-values to break ties between
states at the same plateau depth - might help a (very) little when searching at
the depth where a plateau escape lies, though shouldn't do too much to the quality.)

OK, I now see that I was confused by the different kinds of evaluation going on
(g vs. h). The search indeed looks lazy.

One thing where I'm unconvinced is whether it's a good idea to put complete
states into the open list -- I fear that in a domain like Satellite, this can be
several orders of magnitudes more memory-intensive than the
parent-pointer/operator pointer pairs used by the old lazy BFS implementation.
(Not sure about the new one, don't know it well enough.) I think this is a
general topic we should discuss at some point (see also issue23).

Anyone have any opinions about the cost vs. depth issue?

No, it's probably me. :-) I'm not at all familiar with the evaluator code, so I
probably misread something. I'll look into the code again when I have a bit more
time.

One thing I was wondering about when looking at the code is whether EHC in
cost-based planning should use the g values as a measure of "escape distance" or
just the search depth. That's essentially the question whether you want to
escape plateaus *cheaply* or *quickly* -- probably something that should be
configurable?

It's actually a lazy search (or at least it's supposed to be).
After a state is removed from the open list, I check that it's  new  state, and
only if it is, I evaluate it.

Unless I'm missing something?

The open list thing is now separated into issue62.

Oh, and I agree with Erez that we should have a clear method for open lists.
I'll open a separate issue for that.

Hi guys, from my cursory reading of the code, it looks like it is an eager
search, but duplicates are only checked once a state is popped from the open list.

Am I reading this right? In that case, I would suggest testing duplicates
earlier (and I'm pretty sure Jörg's code does that) to save both time and
memory. Generally speaking, no search algorithm (neither eager nor lazy) should
invoke the heuristic estimator on a state that is a duplicate -- duplicates
should be discarded before computing heuristics.

Not sure how significant this actually is, but if anyone wants to test this, I'd
suggest looking at large Satellite tasks with a good heuristic (e.g. h_FF).

Checked in EHC implementation.
Gabi - if you implement a clear() operation for open lists, we could save some
time here (now I clear the list by looping over it).