Erez: If there's still time for this, the new options should also be
communicated to Chris (new cost_type options for search + no more
use_cost_for_bfs option in EHC).

Merged. We still need to:

1) Test this a bit more thoroughly, and
2) Write documentation.

Unfortunately I have time for neither right now. :-(

BTW, I noticed that even with pruning based on true g value, iterated search
that is based on uniform g will not necessarily converge to an optimal solution
since it won't reopen nodes or update parent pointers when it finds cheaper
paths. That's a large topic in itself, so I don't think anything needs to be
done about it right now, but I've opened issue191 to record this.

I'm currently merging this. In EHC, I've removed the use_cost_for_bfs option
since it just duplicates the behaviour of cost_type=1.

BTW - this has undergone very little manual testing

Sorry, I forgot to mark this as done (I got distracted by the LAMA/FF synergy 
bug).

Promoting this to urgent -- I think we really, really should support a cost_type
option in the search algorithms so that we can have g values in weighted A* that
are based on distance rather than cost.

We should always prune based on true cost, which means we can stick to the
current way of passing in a numerical bound (which can be set from the command
line if the user pleases).

This means we'll need an additional field in the search nodes for "cost" in
addition to g and h. Pity about the memory usage, but cannot be helped.

One possibility is wrapping the relevant code around #ifdefs so that we can at
least get rid of it in the builds for the optimization track.

The whole concept of pruning based on "best plan known so far" is questionable
when the search algorithm doesn't optimize the true cost metric, no matter how
we resolve this decision, due to the mismatch regarding what the search
algorithm optimizes and what we really want to optimize.

For example, if the searches are based on distance (= unit cost) and we quickly
find a plan of distance 1 but with huge cost, we really don't want to prune all
plans of distance >= 1 in the next iteration.

Maybe let's resolve this quickly over the phone? I can't go on Skype right now,
but I can call you on the phone if you can give you me your number, or you can
call my phone from Skype. My phone number is on my website.

After some more thought, just passing the plan blindly is not such a good idea.
We currently pass the "best" plan found so far as the bound.
Consider an iterated search which uses different cost adjustment methods in 
different searches, and has already found 2 different plans.
One of them is the "best" according to NORMAL plan cost, and another
is the "best" according to UNIT plan cost (i.e. shortest).
Without knowing what type of cost adjustment the next search is using, it's not 
clear what the correct plan to pass is.
Of course, we can always just use the last plan, but I can think of examples 
where this would be wrong.

> I'm not sure passing the plan is feasible, since the bound is also a command 
> line parameter.

I don't think it has to be -- at least for the IPC, I'd suggest simply removing
this parameter. We can think of fancier things later.

> Another question - I noticed that the domain transition graph uses operator 
> costs (in the ValueTransitions). Is this part of the adjustment for the
> cg/cea heuristics, or should I take care of this as well?

So far, this is just to discriminate axioms (cost 0) from regular operators
(cost 1). I'll take care of that once I get to implementing cost supports for
these heuristics.

I'm not sure passing the plan is feasible, since the bound is also a command 
line parameter. I suggest we pass two bounds: plan cost and plan length. Then 
the adjusted bound is either: cost, length or cost+length. 
That is, unless we might introduce other cost adjustment type, in which case we 
need a better solution.

Another question - I noticed that the domain transition graph uses operator 
costs (in the ValueTransitions). Is this part of the adjustment for the cg/cea 
heuristics, or should I take care of this as well?

> I've started working on this, and there are a few decisions to make:
> 1. In iterated search, when passing the plan cost bound to the next search, 
> should it use the real plan cost or the adjusted plan cost. Keep in mind - 
> different iterations might use different cost_type adjustments. Maybe it
> should use the adjustment of the next search?

I think that only the adjusted plan cost of the next search makes sense
semantically. In my mind, the easiest/cleanest way of implementing that without
poking around in the new search, is not to pass in a *cost bound*, but rather
pass in the actual *plan*. The search can then convert that into a bound by itself.

> 2. When outputting a plan (to stdout) should the real or adjust costs be
> reported (for each action and for the entire plan)?

Real.

I've started working on this, and there are a few decisions to make:
1. In iterated search, when passing the plan cost bound to the next search, 
should it use the real plan cost or the adjusted plan cost. Keep in mind - 
different iterations might use different cost_type adjustments. Maybe it should 
use the adjustment of the next search?

2. When outputting a plan (to stdout) should the real or adjust costs be 
reported (for each action and for the entire plan)?