UP-BFGP interface v0.2.0, few-shot engine and BFGP++ generalized planner v0.1.0 #514
Conversation
Gp planner
Aiplan4eu master
Final Deliverable merge
| def is_fewshot_planner() -> bool: | ||
| return True | ||
|
|
||
| def solve( |
There was a problem hiding this comment.
I think we should rename this method, otherwise it would conflict with the OneshotPlanner Operation Mode, making it impossible to have an engine supporting both FewshotPlanner and OneshotPlanner
There was a problem hiding this comment.
I see a OneshotPlanner a specialization of a FewshotPlanner, so if some software could do both, then it is a FewshotPlanner, i.e. a OneshotPlanner is a FewshotPlanner that always works with one instance.
| This method takes a list of `AbstractProblem`s and returns a `PlanGenerationResult`, | ||
| which contains information about the solution to the problems given by the generalized planner. | ||
|
|
||
| :param problems: is the list of `AbstractProblem`s to solve. |
There was a problem hiding this comment.
Do you have any assumption on the structure of these problems? What happens if they come from radically different domains?
There was a problem hiding this comment.
If we have such assumptions we need to make them explicit in the OM
There was a problem hiding this comment.
It assumes the domain is shared for all instances.
You can see an example in the UP-BFGP interface.
| ) -> List["up.engines.results.PlanGenerationResult"]: | ||
| """ | ||
| This method takes a list of `AbstractProblem`s and returns a `PlanGenerationResult`, | ||
| which contains information about the solution to the problems given by the generalized planner. |
There was a problem hiding this comment.
Explain how this is different from calling a OneshotPlanner n-times
There was a problem hiding this comment.
The main purpose of a FewshotPlanner is to produce domain-specific knowledge that i) inform about the structure and complexity of the solution for any instance in that domain, and ii) scales up to larger and more complex planning instances. Thus, it must be more scalable than calling a classical planner n times on new and larger planning instances, if the domain knowledge is computable in reasonable time and memory.
| return self._solve(problems, heuristic, timeout, output_stream) | ||
|
|
||
| @abstractmethod | ||
| def _solve( |
There was a problem hiding this comment.
Also this method neds to be renamed to avoid clash with OneshotPlanner
This code is required for the Final Deliverable of the "Integration of a Generalized Planner in the Unified Planning Framework" project.
The PR includes a new engine to do few-shot planning, where the input is a set of problems in a given domain. Also registers a new planner named BFGP whose interface can be found in the up-bfgp repository.