simple translation to SAS+

[blaszcz...@gmail.com]

Hi All!

I'm implementing a PDDL-like planner as a self-educational project. I've already got STRIPS working and now I want to move into simple form of SAS+. The idea is to grasp just SAS+ essentials needed to perform planning. The planner will use Hammond heuristic (i.e. unsatisfied variables count), grounding will use simple naive algorithm, there are no conditional effects or quantifiers or fluents. I'm wondering if I need to calculate DTG and CG at all? Are these used only for CG heuristic or are they also needed in the process of translating PDDL into SAS+?

In general, if I have a normalized STRIPS problem, what is the minimum I need to do to get it transformed into SAS+?

Best Regards,

Jakub Błaszczyk

[Malte Helmert]

Hi Jakub,

I just found your email buried in my inbox, and I think nobody replied
to it yet. Sorry to let it linger for so long.

DTGs and CG are not necessary for most heuristics, and in fact right now
Fast Downward only computes them in the translator/preprocessors for
output file compatibility reasons. They are ignored by the search component.

The main question is: do you want to perform the invariant synthesis to
group multiple binary state variables into a single finite-domain
variable or not? This is the only real difference in STRIPS vs. SAS+,
but for the heuristic you're intending to use, this compilation doesn't
make a difference anyway. So in that case I don't think there is a real
benefit in using SAS+.

I'm not sure if this helps answer your original question. If not,
perhaps you can elaborate, and hopefully this time we'll answer more
quickly. :-)

Cheers,
Malte

[blaszcz...@gmail.com]

Hi Malte,

Thanks for the reply, I've read your paper "Concise finite-domain representations for PDDL planning tasks" and

kinda came to similar conclusions but it's still good to hear them confirmed :)

In this simple project I took iterative approach: implement end-to-end planner with naive/trivial algos whenever possible and improve them later on in future iterations.

I don't perform invariant synthesis just yet, so I'll end up with one SAS+ variable for each predicate I guess.

However I don't understand why do we compile away types during translation. Some planners out there handle types directly in the search logic. Are those generated "typing predicates" necessary somewhere else?

Best Regards,

Jakub

[Malte Helmert]

Hi Jakub,

the reason we compile types into static predicates is because it was the
simplest way to deal with types. You have to support static predicates
anyway because they occur in PDDL inputs, and since types in PDDL are
just syntactic sugar for such static predicates, the least-effort way of
handling them is to compile them away.

So there is no deep reason, it's just that this was the most convenient
thing for us in terms of the implementation.

Cheers,
Malte