Regarding max arity of predicates

0 views
Skip to first unread message

Miguel Ramírez

unread,
Feb 18, 2008, 5:05:21 AM2/18/08
to ipc-...@googlegroups.com
Hello all,

I would like to ask about the maximum arity of predicates we will find
in the competition problems. A rough estimate would be good enough.

Thanks,

Miguel Ramírez

Malte Helmert

unread,
Feb 18, 2008, 12:57:58 PM2/18/08
to IPC-2008
Miguel Ramírez wrote:
> > Hello all,
> >
> > I would like to ask about the maximum arity of predicates we will find
> > in the competition problems. A rough estimate would be good enough.

Dear Miguel,

off the top of my head, the highest predicate arity I remember seeing
in previous IPC domains is 4 (e.g. in Airport-ADL, Philosophers and
Optical-Telegraphs). You should definitely be able to handle that.

It's not particularly likely we will need more than that, but would it
be a problem to support an arity of, say, 6 or 8? Not that we will
need 8-ary predicates, but if we're going to have arbitrary limits,
I'd prefer them to be rather unconstraining.

Best regards,

Malte

Miguel Ramírez

unread,
Feb 18, 2008, 1:57:59 PM2/18/08
to ipc-...@googlegroups.com
Thanks for your answer Malte :)

Miguel Ramírez.

--
Dept. of Information and Communication Technologies - Universitat Pompeu Fabra
------------------------------------------------------------
Artificial Intelligence Group
------------------------------------------------------------
Es la virtud del trabajo
la desdicha del obrero
que quien trabaja no tiene
tiempo de ganar dinero

Miguel Ramírez

unread,
Feb 19, 2008, 4:05:35 AM2/19/08
to ipc-...@googlegroups.com
Hi,

forgot to answer to this part...

>
> It's not particularly likely we will need more than that, but would it
> be a problem to support an arity of, say, 6 or 8? Not that we will
> need 8-ary predicates, but if we're going to have arbitrary limits,
> I'd prefer them to be rather unconstraining.
>

My question was motivated by the grounding process. The grounding I
have now implemented has a very big problem handling really problems
like Pipesworld, when one has to generate literally millions of
grounded ops. When doing profiling I found out that my procedure to
assign an index to a grounded predicate was taking something like
40%-50% of the overall planning task "pre-process" time.

Looking at what FF does I noticed that FF builds a huge index table
implemented as a static C array with as many dimensions as the maximum
arity. The problem exactly lies in how to define the type of the index
table in an "unconstraining" manner. I have been looking into
expression templates - so the type gets "computed" in compilation time
- but I don't think it is feasible at all or at least haven't ever
heard about anything similar.

I think I will settle for the humongous static array :(

Miguel Ramírez.

Malte Helmert

unread,
Feb 22, 2008, 1:43:48 PM2/22/08
to IPC-2008
On Feb 19, 10:05 am, "Miguel Ramírez" <miquel.rami...@gmail.com>
wrote:
> Hi,
>
> > It's not particularly likely we will need more than that, but would it
> > be a problem to support an arity of, say, 6 or 8? Not that we will
> > need 8-ary predicates, but if we're going to have arbitrary limits,
> > I'd prefer them to be rather unconstraining.
>
> My question was motivated by the grounding process. The grounding I
> have now implemented has a very big problem handling really problems
> like Pipesworld, when one has to generate literally millions of
> grounded ops. When doing profiling I found out that my procedure to
> assign an index to a grounded predicate was taking something like
> 40%-50% of the overall planning task "pre-process" time.

I guess the short (but code-intensive) answer to that is a more
sophisticated grounding procedure.

You may try to use something "off the shelf". I think that VAL
includes grounding tools, and I seem to recall that the grounding code
of FF and/or MIPS is or was available separately. You may also be able
to do something with the LPG code, or with Patrik Haslum's HSP-family
planners or pddlcat. I don't have extensive experience with any of
these, so I don't know how they perform, but they're certainly worth a
try. (Maybe some of the respective authors want to chime in, if they
are reading this?) Of course, if you intend to use any of these, check
their licences first to see if you'll be able to include them in your
planner, also with respect to this year's competition's policy about
opening the code. You can also use Fast Downward's translation and
grounding code (just contact me directly), but I know that it has bugs
in relation to some ADL features.

Alternatively, if you want to implement something yourself, you can
look at pages 26-33 of technical report 217 at
http://www.informatik.uni-freiburg.de/tr/complete.html.

Best regards,

Malte
Reply all
Reply to author
Forward
0 new messages