Skip to content
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

Support for :domain-axioms requirement #65

Open
beasteers opened this issue May 16, 2023 · 4 comments · May be fixed by #66
Open

Support for :domain-axioms requirement #65

beasteers opened this issue May 16, 2023 · 4 comments · May be fixed by #66

Comments

@beasteers
Copy link

Is your feature request related to a problem? Please describe.
This parser doesn't support axioms, which are used in this paper.

Describe the solution you'd like
Let's add axioms to the parser! I already have a PR brewing, hopefully you'll be interested in the addition.

Describe alternatives you've considered
I've noticed that derived predicates are very similar, but axioms have a richer language for implications which is why I think they could be a good addition. rewriting the axioms in the PDDL might be difficult due to negated predicates, but I'm not an expert.

@beasteers beasteers linked a pull request May 16, 2023 that will close this issue
6 tasks
@haz
Copy link
Contributor

haz commented May 25, 2023

Hey @beasteers , welcome and thank you so much for throwing your weight behind this! To be honest, I had to go down a few rabbit holes to try and sort things out, since I've never come across :axioms in my days as a PDDL user (I've had quite a few such days by now :P).

My best read is that :domain-axioms were introduced in an early version of PDDL (1.2 or so back in the late 90's), but then promptly discarded due to lack of use and confusion about how to handle them best. What swooped in to replace is :derived-predicates, and (as you point out) they serve nearly the same purpose, albeit with a slightly different form factor. One of the landmark papers that discusses the area is here.

While there is some reasonable support for derived predicates (the field's leading planning framework supports it), I don't think the same can be said about axioms. Not sure if we could get any of the small handful of planners that used them compiled again (bit rot of roughly 2 decades now).

So where does this leave the request & PR? Aside from a fairly minimal test file, it's a pretty solid contribution. My worry is the taking on the technical debt to maintain the functionality with minimal impact/use. Did you have a specific reason to need explicitly axioms? If it was for that paper you link to, would it help if we instead helped devise a converter of their domains (i.e., domains with :domain-axioms) to ones that use :derived-predicates? I can imagine a custom solution to rewrite them could be readily whipped up and then everything is back to the known/adopted setting of :derived-predicates.

Ultimately, I think this is a call for @marcofavorito and @francescofuggitti to make -- the main authors of this lib. But I do have an invested interested in derived predicates / axioms in general, so very much want to understand the implications of whatever choice is made.

@beasteers
Copy link
Author

I totally understand about the technical debt so I'm okay if this PR gets discarded (I can always use my fork) and honestly, it felt a bit weird putting it on the same level as actions in the code for a "low usage" feature. So if there were a way to have this kind of feature be less intrusive, that would have been preferred. I'm not extremely well-versed in the PDDL ecosystem (especially planners) so I found it hard to determine what directives are irrelevant and which are niche and just hadn't been written yet.

Essentially, I had a need to parse files with this directive (even if I did want to convert axioms to derived-predicates, I'd need a parser), so I was left to either implement my own generic parser or extend this one and I figured it might be useful to someone else.

I suppose a one-off somewhat hacky regex script and a group-by could do the conversion job technically, but I couldn't tell if derived-predicates and axioms were exact inverses. It looks like axioms are functionally more like constraints on the list of predicates, while derived-predicates are more like "calculated predicates" so I'm still not sure if they're directly translatable If having a converter can fully translate them then that's great.

@haz
Copy link
Contributor

haz commented May 25, 2023

@nergmada I've noticed this trend a bit as well, as my students stumble upon the wiki and bring a question to class on "why can't I use this esoteric feature XYZ in my models?", and my only answer is "What the deuce are you talking about, XYZ?!?" (as a co-author of the book on PDDL, it strikes me as odd). Any chance we can get a little less coverage, or at least a special designation for the proposed features that never made it into the mainstream?

@beasteers your hunch is on the money -- it's a special set of auto-derived predicates that would be used. There are circumstances where derived predicates won't be able to handle precisely what the axioms are doing, but the important question here is if your setting is one of those circumstances. If you'd like to bring the domain to the planning slack (I see you've already found it ;)), then perhaps we could work through things over there on the PDDL channel. At the very least, help figure out if axioms were/are required, or if derived predicates will do.

@francescofuggitti
Copy link
Collaborator

Hi @beasteers, thank you for your contribution! Thank you, @haz, for sharing your ideas on the topic.

Given the low current usage of axioms, their blurred relationship with derived predicates, and the fact that @beasteers can safely use the local fork, I guess that, at this moment, the best (and safest) pick would probably be better to understand the relationship between axioms and derived predicates first and then consider adding axioms to the lib officially.
Anyway, I don't have a strong opinion on that, so as soon as a contribution is solid (as this is -- I'd just add some more tests) and is not "harmful" to other lib's features, then it can be added.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants