> My plan is to make a draft/PR of such a "search algorithm" once issue1201 is resolved.

My impression is that we need to discuss where we (as a group) want to go first regarding this suggested feature. I appreciate the willingness to add such a feature, but I wouldn't want to add it -- I find the current situation preferable to the scenario where we have this additional feature.

If you really want to push for this feature, please discuss it first, don't go to an implementation before we have agreed that we want it. (And in that case, let's do this as a live discussion, not a text discussion. It will be much quicker.)

> Why would an anytime or portfolio planner set the bound to 0 and run the search?
> What information does it gain from it?

Because they set the bound for the next planner call to the bound of the best plan found so far, which can be 0 (but never negative).

For example, you can see this in the code of Fast Downward's satisficing portfolios and in the code of Fast Downward's anytime search, which would both crash on tasks with optimal plan costs of 0 if we made bounds of 0 illegal.

There is nothing weird or buggy about doing it this way, and we do this fully intentionally.

My plan is to make a draft/PR of such a "search algorithm" once issue1201 is resolved.

@msg12001

Why would an anytime or portfolio planner set the bound to 0 and run the search? What information does it gain from it?
How would it be better than a fork of said anytime or portfolio planner that does everything the very same but just skips this call because it knows that the answer will be "no plan was found"?

If the argument is that the algo computing the bound might do something weird, then why do we not allow all integers, even negative ones?

In msg2849 the argument was: 
<<The logical answer to the question "Try to find a plan that costs less than zero" is "There is no such plan", not "Error!".>>
With the same argument one should allow negative values(?) otherwise what is the logical answer to the question "Try to find a plan that cost less than negative 42"? Is it a different answer to "Try to find a plan that cost less than zero"?

That it reports the h value of the initial state is nice for testing but it is doing weird computations that do not help answering the given question "Try to find a plan that costs less than zero".
If the initial h value report is a feature we want to provide we should make it an actual feature and not hide it in an unintuitive searchalgo call.

If the bound parameter was treated inclusively instead of exclusively everything would be index shifted by one.
For me that would not feel weird to represent bounds in this form (I am not suggesting to do it, it would just not feel like a hiccup for me)
Would an anytime planner call a search algorithm with bound=-1 then?
Calling a searchalgo in this scenario with bound=-1 would in fact feel weird to me.

In an offline discussion Malte thought about having other components as entry point. So a CLI input could be just "blind()" instead of "astar(blind())" to compute the initial h value of the blind heuristic.

I think this could be difficult and I am not fully convinced by that.

In offline discussions I asked Clemens, David and Florian why they use a search with bound=0 and they said it is for the initial h value only (and not being spammed with things that happen with 0 cost operators).
Is there more to consider?

If no I would suggest to treat bound=0 the same as bound=-42 (either disallow both or report that no plan for the bound exists without doing heuristic computations) and add a feature "init-h(blind())" that just reports the initial h value.
It would be a searchalgo as component type to not add logic about the entry points.

[Malte on discord]

That is not consistent with the other behaviour and should be considered a bug.

[Simon on discord]

Oh, with `bound=0` it is actually possible for fastdownward to find a plan if the initial state is a goal state.

[Maltes answer from discord]

I frequently set the bound to 0. It's a way to run the search component if you're only interested in the early output, and then terminate. I think it's generally a bad idea to say that a corner case "doesn't make sense". It breaks all kinds of uses that expect corner cases to be handled correctly, for example all anytime or portfolio solvers where the bound is set by an algorithm.

[Davids answer from discord]

I frequently use bound=0 . It is extremely helpful if you want only to determine the heuristic value of the initial state. I would be pretty sad to lose this option :^) .

On discord I mentioned some things I found weird about fast downward. One is basically this issue:

We can call a search algo with a bound of 0. Initially, I thought this would restrict it to finding plans with a cost of 0.
   But the bound is exclusive (as mentioned in the docs).
   If you set bound=10 it only looks for plans with a cost up to 9. Therefore, it does not make sense to ever set the bound to 0.
   I think the bound parameter should be set to [1,infinity], to prevent the user from executing something unintended.
   Currently, it allows any integer, including negative ones.
   However, this results in error code 33 "SEARCH_INPUT_ERROR: Wrong command line options or SAS+ file."
   This is the correct error code but it occurs too late.
   If you call 'astar(weight(hmax(),-1), bound=-10)' it will "successfully" read the input and start more of the search engine than it should
```
[t=0.000334s, 45748 KB] Search code revision: bfbdc851e-dirty
[t=0.000745s, 45748 KB] reading input...
[t=0.001243s, 45748 KB] done reading input!
[t=0.003728s, 46004 KB] Simplifying 66 unary operators... done! [66 unary operators]
[t=0.003915s, 46004 KB] time to simplify: 0.000257s
[t=0.004000s, 46004 KB] Initializing HSP max heuristic...
[t=0.004085s, 46004 KB] Building successor generator... done!
[t=0.004226s, 46004 KB] peak memory difference for successor generator creation: 0 KB
[t=0.004263s, 46004 KB] time for successor generation creation: 0.000039s
error: negative cost bound -10
```

While we're looking at it, there's a related thing we're not currently handling
properly, and that's if the initial state should be pruned because of its
heuristic value.

Currently, we add it to the open list unconditionally, and this happens to work
by accident, but the output is messed up (e.g. showing that a state with a
heuristic value of 2147483647 is expanded). This also causes an
out-of-memory-style error when using single_buckets() since the code attempts to
create 2147483648 buckets. For example, try

$ ./plan ../benchmarks/mystery/prob07.pddl --search 'eager(single_buckets(blind()))'

The better solution would be to use the same criteria (and ideally the same
code, factored out) as during state expansion for deciding whether the initial
state should be added to the open list.

I find it also more naturally to report that there is no plan
cheaper than 0.

> 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).

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.

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?

> I would suggest to forbid setting bound=0.

Why? This seems like an arbitrary limitation to me; I'd rather see the
underlying bug fixed. This would also mean that nothing needs to be done about 2).

The first briefcaseworld task is solved by the empty plan. This uncovered two 
bugs:

1) Even with the exclusive g-bound set to 0 the empty plan is accepted as a 
solution. I would suggest to forbid setting bound=0.

2) Satisficing portfolis repeatedly find the empty plan, set the bound to 0 and 
find the empty plan again... I would suggest to alter portfolio.py and stop once 
the bound falls below 1.