search

domschrei / lilotane

Lifted Logic for Task Networks: SAT-driven Planning for Totally-ordered Hierarchical Task Networks (HTN)
GNU General Public License v3.0
28 stars 7 forks source link

What are the limits of lilotane? #2

Closed fire closed 4 years ago

fire commented 4 years ago

I saw the difference of totally-ordered vs partial order and recursive vs non-recursive.

What limits are there to using lilotane compare with other planners and the winner of the competition?

domschrei commented 4 years ago

So in the competition there were supposed to be four tracks: the cartesian product of totally-ordered vs. partially-ordered and recursive vs. non-recursive. However, I think there are just no serious HTN planners which do not support recursive domains nowadays, so these two tracks did not take place. The winner of which you speak participated in the same track as Lilotane, i.e., they have the same "theoretical" capabilities. In particular the subtasks of every method definition must be totally ordered (a restriction which makes totally-ordered HTN planners much faster, but makes them lose the ability to find solutions for undecidable / semi-decidable problems). If you take a look at the partially-ordered track, there are only two (not disqualified) participants, and you can see how they performed in the total-order track compared to HyperTensioN or Lilotane.

In practice, to put it in a nutshell I would say that Lilotane is often a bit slower when the domains become large (Lilotane won 1/3rd of all domains regarding a highly runtime-oriented score while HyperTensioN won basically the other 2/3rd), but Lilotane often finds smaller plans (which are more natural when seen in action) and by now solves a few more instances on the benchmarks, at least compared to the competition version of HyperTensioN. Also, if you have a fixed time frame allotted for planning you can supply this limit to Lilotane and it can improve the plan as long as there is time left.

In the end it will depend on your particular use case which planner is the better choice. Maybe also consider a parallel portfolio of both approaches if that is feasible (run both in parallel, first to report a plan makes the other one shut down too) – I could well imagine this duo being quite unbeatable :)

fire commented 4 years ago

Thanks, this resolves my question.

Edited:

Regarding your proposal of doing both. I don't think any of the other planners are in C++ and running both would require a port.