looping task?

[ko56]

Can you explain (or point to a paper) what a "looping task" is?

[rpgoldman]

Looping tasks are an in-progress facility that @ukuter has been working on for some time now. Essentially, these are tasks that expand to a variable number of subtasks where that set of subtasks can be computed at planning time (i.e., the expansion is not a function of something that must be observed at execution time).

The conventional solution to building plans with tasks that have a varying numbers of subtasks in recursion: handle a set of items by

1. handle the first item, and then
2. recursively handle the remaining sub-items

This works fine, but yields extremely ugly and large plan trees. @ukuter developed looping tasks to allow us to have plan trees where the set of subtasks for something like "unload 10 trucks" is a single node with 10 subtasks, instead of a 10-deep binary tree.

[ko56]

Thanks, I was hoping it would be something like that. I am dealing with such situations now, where the same (sub)task has to be performed on a set/list of entities.

I am doing by applying a method recursively, and create atoms to mark the elements of the list that have been processed. (Haven't been able to come up with another way.)

If you do that, it seems to me that the plan tree is straight line. What do you have in mind that makes it a binary tree?

[rpgoldman]

The way we have typically done it, we end up with a very "right-heavy" binary tree, where at each level there is generally one (or more) primitive action(s) and then a subtree to the right for the recursive call.

We have used two different ways to handle the control of recursion:

1. (The one you describe above) Find all the entities that need processing, process one, ensuring it is somehow marked as processed, then recurse. At each level, you retrieve the set of entities that need processing, and if you fail, you are done, if not, you process one.
2. Possibly more efficient: initially retrieve all the entities that need processing using something like setof, and bind a variable to this list. Now you can use a pattern like this:

(:method (process-all ?list-var)
   (= ?list-var (?first . ?rest))
   (:ordered (process-one ?first) (process-all ?rest)))
   (= ?list-var ())
   ()) ; we are done

[ko56]

Ah, nice. I will try your 2nd method.
On a different topic, how is the new method syntax coming along?

[ko56]

With respect to list processing, I try

(defdomain tlist
  (
    (:method (pl ?L)
      doit
;      (and (assign ?f (first '?L)) (assign ?r (rest '?L)))
      (and (= ?L (?f . ?r)))
      ()
      )
    )
  )

(defproblem p1 tlist
  ()
  (pl (a b c d))
  )

(find-plans 'p1)

This says inapplicable method DOIT, I don't understand why. The commented line above works.

[rpgoldman]

Likely the problem is that unless you use a domain class that automatically provides it, you don't have the Prolog-style unifies axiom:

(:- (= ?x ?x) ())

Try adding that, and things should work.

Alternatively, you could have:

(defdomain tlist
  (
    (:method (pl (?f . ?r))
      doit-and-recurse
      (:ordered
        (!handle-one ?f)
        (p1 ?r)))

    (:method (pl nil)
      done
      ()
      ())
      )
    )
  )

(typed directly into the web page -- quite likely there are errors!)

This would be a good thing to put into the manual as a FAQ about writing domains.

[ko56]

The axiom did it. This indeed needs to go into the manual.

My initial interpretation was that in (and (= ?L (?f . ?r))) we have a SHOP3 atom, consisting of the predicate =, the term/variable ?L, and the list term (?f . ?r). In sec. 4.1 of the manual, what "predicates" SHOP3 understands is never actually defined, so I assumed = must be a built-in one. What the built-in predicates are needs to be clarified.