Forward search with tarski
#101
Replies: 4 comments 20 replies
-
I haven't been following the channel lately, but it's not even a matter of Python (which of course it also is), it's also that Tarski aims at having a clear design for representing planning problems, not so much for solving them. I have added that module But: other options for running more efficient searches on a Tarski problem include interfacing with Pyperplan (I've done that in some projects, and have a few lines of code to easy transform any Tarski state into a Pyperplan state), or, why not, to interface directly with Fast Downward. The advantages of the second are obvious; the disadvantage is that it's a monolithic solution, and you can only ask for a plan, but cannot ask the library useful things such as "give me all nodes at distance at most 4 from this state", etc. If there is interest, I have code for that too as well, which could be easily integrated into Tarski (actually it's a very silly code: just print instance and domain to two temporary files, invoke Fast Downward as a subprocess, parse the output). |
Beta Was this translation helpful? Give feedback.
-
So our use case here (1) doesn't need the performance; and (2) would suffer entirely the more you tie into C++ and bind. I actually strongly prefer to have a version of tarski that's as close to pure as possible. We want to embed tarski in the browser, so that we have functional access to all the niceties it offers for things like plugin development. We need to parse PDDL, ground it (working on seeing if Gringo will fly, but more naive grounding that just filters on types would be useful as a backup), find the actions applicable in a state, and run progression. Need a full plan? Call solver.planning.domains (it's about to be equipped with far more than just lapkt). So I assume [this] is the extent of what we have access to as far as successor generation? Looks like it violates the |
Beta Was this translation helpful? Give feedback.
-
Ouuch great catch, Christian! That looks like an unused piece of code that shouldn't be there, actually what I use is this other method that does indeed respect the add-after-delete semantics. I'd say we can fix the G. |
Beta Was this translation helpful? Give feedback.
-
Not barging in at all @felipe Meneguzzi ***@***.***> that
is a useful pointer, and indeed, the planning analogue of what I was
thinking of.
…On Wed, 12 May 2021, 19:15 Felipe Meneguzzi, ***@***.***> wrote:
Sort of barging in here, but given the context, I reckon he means
something along the lines of Mau's search space visualizer in Web Planner:
https://link.springer.com/chapter/10.1007/978-3-030-38561-3_11
I can see how expanding things on demand as you render rather than
generating a huge file expanded on one go could be useful.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#101 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADMQKKPK6CXNBLZ3MUH3R3TNJBKBANCNFSM44JCCB2A>
.
|
Beta Was this translation helpful? Give feedback.
-
Following up on the query by Christian Muise on the Planning Community Slack channel, I would like to direct folks to the simple blind search engine for STRIPS planning available in the module
tarski.search
.We strongly recommend writing your own search engine in a language more performant than Python.
Beta Was this translation helpful? Give feedback.
All reactions