[fud2] Planner Based Around Inductively Defining All Constructable States#2616
Open
[fud2] Planner Based Around Inductively Defining All Constructable States#2616
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I came up with this writing up fud2 for latte and trying to prove this planner problem NP hard w.r.t. the number of ops and states. Uhhh, I think the problem isn't actually that hard and this just kind of works and is actually okay-ishly efficient.
The big idea here is to keep a set of creatable states and iteratively look through every op to see if it's inputs are satisfied. If its inputs are satisfied, add the op's outputs to the set of creatable states and write the op down as used. This will find all creatable states from an input set.
However, this likely will create too large a set of ops, so this set is pruned. Ops whose outputs are redundant to other ops or whose outputs are never used are removed. This is iterated until ops stop getting removed.
It is possible for valid plans to exist this algorithm does not fine, but I think it does a pretty good job. It passes tests at least...
The complexity analysis on this one is a bit hard because it requires thinking up annoying worst case counter examples, but I can bound it by O(Ops^2 * States). The construction and pruning stage have nice symmetries where both require iterating over every op and each of those ops's inputs/output (the ops * states parameter) with an amount of iterations bound by the number of ops.