Incremental postsolve in TD3 #372
Merged
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.
Closes #368.
This PR is built on top of #370. It makes TD3 implement its own top-down postsolving, which additionally knows about all the TD3-specific incremental data structures to know what definitely doesn't need to be re-evaluated.
For verify, it uses a
superstableset, consisting of loadedstableand every removal fromstablepermanently removes the node fromsuperstable. Nothing ever gets added back there. After solvingsuperstablecontains all the variables that were continuously stable, hence definitely unchanged. These are considered the initiallyreachableset, which stops the top-down verify naturally.Incremental warnings are a pain though: the correct constraint system
Varmodule for hashtable usage is just available inside the solver itself. So TD3 hooks into the right-hand sides and the message system to know which warnings come from where.Incrementally, the warnings at
superstablenodes still apply, the rest gets filled in by postsolving again and recorded invar_messagesfor incremental re-save.This is quite hacky, but the best we can do without putting warnings into the domain (which would have numerous bigger issues on its own).
Also this breaks race detection warnings because
Accessmodule uses its own global hashtables that are correctly filled in only when the entire program is re-verified. Incremental verification therefore gives incomplete race warnings and without major redesign of race warnings, it's not possible to get them incrementally.