-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AStar solver not implementing _solve_domain as expected #218
Comments
@g-poveda Could you develop about
? Because, it seems to be the same behaviour for other c++ solvers (probably there are all wrong in that by the way):
The only c++ solver that seem to implement a real
|
@nhuet The pure python solvers in the hub : |
I would challenge that one and call for a discussion. But in any case, I agree that we should agree on a common consistent behaviour but first discuss what should be this behaviour. By the way, the same is valid for the solvers' constructors which have different signatures between pure python and C++-based solvers |
Ok agree @fteicht , i think i raised this issue to get more consistency and actually the solve_from() probably has its advantages. |
Agree. I propose to change the behaviour of the C++ solvers so that _solve_domain will actually call the solver if the domain provides a default initial state. If not, _solve_domain will continue just initializing the solver, whose search will be launched only when calling _solve_from (which is the current behaviour of all the C++ solvers). |
Also, the |
Solved by #320. |
the AStar solver :( skdecide/hub/solver/astar/astar.py ) doesn't seem to solve actually the domain when calling
_solve_domain
method. It just initialize internal solver (coded in cpp) but don't run the solve. This seems different from other hub solvers and scikit-decide api in general.(currently, the actual solving is when calling solve_from(memory))
The text was updated successfully, but these errors were encountered: