-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Subtype Incompatibility Error with Predicate Term Types #98
Comments
@mgkwon thank you very much for your interest in using |
Hi! I'm facing the same issue and was wondering if there are any updates regarding this. Is there any quick workaround to make subtypes compatible with predicates? On a related note, I'm searching for the correct way to declare subtypes when defining the domain, if that is supported by the library. Any tips would be appreciated! For example:
returns a type parsing error. |
Hrmz...from the first example, it doesn't look like you have any sub-type information put in. Here's an example of how sub-typing can be done:
That said, it doesn't look like the Variable object is associated with the domain (similar with the predicate). @marcofavorito should the Domain object (containing type hierarchy) be used in some way for the validation of parameters? |
Hi, @fenjenahwe the Hence, in your example, you should write: types={
"objects": "world",
"location": "world",
"hypothesis": "world",
"agent": "objects",
"furniture": "objects",
"consumable": "objects",
} Regarding @mgkwon's issue, yes there should be a check in the |
Thanks @haz
My understanding is that it should translate into:
the dash symbolizing a subtype relation (?) - unless I have misunderstood this (if so, would appreciate any resource I can look into to understand this). For the second point, yes I believe this is the main issue - even when I manage to have a type hierarchy (cf. below), if a Predicate's parameter is supposed to have type C, then a parameter of type B will be rejected and return an error because it is understood as a separate/independent type (regardless of type hierarchy in the domain). My current workaround (yikes, brace yourselves): Line 30 in 8e3be08
Then disabled ( 😁 ) the lines that validate the types used in Predicates. Lines 73 to 76 in 8e3be08
Doing this, I obtained a correct PDDL description of the domain/problem and was solvable. |
Thanks!
My understanding is that these are just types that are independent from each other? Or am I missing something.. |
This is another issue (different from the original one); I will make sure this is documented in another GH issue, and then addressed. Thank you very much for the report! |
Regarding @mgkwon's issue, I think a good solution would be to pass the type hierarchy definition inside the p = Variable("p", ["person"])
l = Variable("l", ["location"])
l_city = Variable("l_city", ["city"])
at= Predicate("at", p, l, types={...}) Basically, the argument The change is less straightforward than previously thought, and since a lot work has been done in this work-in-progress PR (#84) I suggest to include the fix to this issue in that line of work. |
Should likely have a default for the types parameter so we don't need to specify it, ya? |
Subject of the issue
When a predicate is defined with a type and is called in other places such as an action precondition with a subtype as a term it fails due to the assert in:
Predicate.
__call__
I just started getting my hands on PDDL so I'm not sure if it is a good practice to utilize the hierarchy of the types. However, PDDL allows me so it should also be allowed. Please let me know what you think.
Your environment
Steps to reproduce
Expected behaviour
The at predicate should allow the use of the l_city term because city is a subtype of location in the type hierarchy.
Actual behaviour
The library raises an error, indicating that the predicate terms' types are incorrect. It does not recognize that city is a subtype of location in the type hierarchy, resulting in an incorrect type check.
AssertionError: Types of replacements is not correct.
The text was updated successfully, but these errors were encountered: