> Setting bound=0 essentially means telling the planner that no plan is
> acceptable since the bound is exclusive. To me this seems like a usage error
> and not something the searches should have to deal with.
Good code supports corner cases properly. If it doesn't, breakage occurs, like
we see with the portfolio script. The logical answer to the question "Try to
find a plan that costs less than zero" is "There is no such plan", not "Error!".
Obviously, there is no reason to call the planner with a bound manually set to
0. But there are many perfectly good reasons for a larger script invoking
multiple planner calls (such us our portfolios) to pass in the "current best
known solution" or something like this as a bound, and there is no reason not to
support the case where the cost of this solution is 0.
Otherwise everybody using the bounds feature must add a special check that the
bound is not zero. For example, our iterated search code also currently relies
on the fact that bounds of zero can be passed in.
> If we go for your proposed solution, I guess we would need to prevent the
> initial node from being added to the open list in all searches' initialize()
> methods separately, right?
Yes; the clean way to address this would be to use the same bounds-checking code
whenever a node is added to the open list, no matter where the node comes from
(initial node or successor node).