|
Created on 2010-12-17.23:07:21 by malte, last changed by malte.
msg2085 (view) |
Author: rpgoldman |
Date: 2012-03-11.18:23:20 |
|
Thanks, Malte. It's not hard for us to force our domains and problems into the
right ordering, since they are programmatically generated, so in the interests of
conformance, we will just do that.
|
msg2084 (view) |
Author: malte |
Date: 2012-03-11.18:13:13 |
|
> Drawing from Derek and Maria's PDDL 2.1 paper, it seems unambiguous that such
> requirements are permitted:
Sorry, I made a bad typo. :-) Instead of
>> :requirements in problem files are not allowed.
I meant to write
:requirements in problem files are *now* allowed.
I changed and pushed the code to accept :requirements in problem files
yesterday, so it should work now. (Your example from issue318 still fails due to
the ordering of objects/init/goal, but if that is changed, it parses.)
|
msg2083 (view) |
Author: rpgoldman |
Date: 2012-03-11.18:10:34 |
|
Drawing from Derek and Maria's PDDL 2.1 paper, it seems unambiguous that such
requirements are permitted:
<problem>
::= (define (problem <name>) (:domain <name>)
[<require-def>] [<object declaration> ] <init> <goal> [<metric-spec>] [<length-
spec> ])
WRT handling these as if Common Lisp keyword arguments, I don't know what to
say. BNF is simply a bad tool if you wish to capture a grammar in which there
are named arguments or any other construct that permits partial order. I don't
have a good sense of where ordering is mandatory in PDDL, and where the
appearance of mandatory ordering is simply an inadvertent consequence of the use
of BNF. I suppose I am just rehashing earlier correspondence.
|
msg2082 (view) |
Author: malte |
Date: 2012-03-11.00:55:04 |
|
:requirements in problem files are not allowed.
Regarding the more general issue, I wouldn't generally be averse to allowing
:keyword parameters to appear in any order everywhere (I think that's the usual
LISP semantics), but I wouldn't want to implement that without word from Derek
et al. that such a change would be appreciated. (Or put differently, it is
probably a bad idea to support this unilaterally.)
|
msg2081 (view) |
Author: malte |
Date: 2012-03-11.00:39:16 |
|
> See issue164 for another example of this, provided by Robert Goldman.
That should have been issue318.
|
msg2043 (view) |
Author: rpgoldman |
Date: 2012-02-06.21:13:48 |
|
The problem seems not to be simply the question of requirements. I seem to also
have trouble because I have been assuming that the contents of a PROBLEM
definition need not be specifically ordered.
The documentation of PDDL seems ambiguous on this point. McDermott's original
Tech Report states clearly that DOMAIN definitions' components may appear in any
order. However, it is silent on the question of ordering of PROBLEM
specifications.
The use of BNF for specifying the syntax does not help, since BNF does not have
a "shuffle" operator to indicate clearly when it is intended that components can
appear in any order.
|
msg2040 (view) |
Author: rpgoldman |
Date: 2012-02-03.23:21:44 |
|
I can verify that FF handles these forms. To be more precise, it is possible that
FF simply ignores them, but it does not cause it to fail in parsing.
|
msg2039 (view) |
Author: malte |
Date: 2012-02-03.22:50:22 |
|
See issue164 for another example of this, provided by Robert Goldman.
|
msg891 (view) |
Author: malte |
Date: 2010-12-17.23:07:21 |
|
The translator only accepts :requirements lines in domain files, but not in
problem files. According to the source I checked (theFox & Long 2003 JAIR paper
on PDDL 2.1), :requirements declarations should also be allowed in problem
files. Haven't checked what FF and VAL do here.
This bug was originally reported by Tomas de la Rosa.
|
|
Date |
User |
Action |
Args |
2012-03-11 18:23:52 | malte | set | status: chatting -> resolved |
2012-03-11 18:23:20 | rpgoldman | set | status: resolved -> chatting messages:
+ msg2085 |
2012-03-11 18:13:13 | malte | set | status: chatting -> resolved messages:
+ msg2084 |
2012-03-11 18:10:41 | rpgoldman | set | status: resolved -> chatting messages:
+ msg2083 |
2012-03-11 00:55:05 | malte | set | status: chatting -> resolved assignedto: malte messages:
+ msg2082 |
2012-03-11 00:39:17 | malte | set | messages:
+ msg2081 |
2012-02-06 21:13:49 | rpgoldman | set | messages:
+ msg2043 |
2012-02-03 23:21:44 | rpgoldman | set | messages:
+ msg2040 |
2012-02-03 22:50:22 | malte | set | nosy:
+ rpgoldman messages:
+ msg2039 |
2010-12-17 23:07:21 | malte | create | |
|