Back translation for Princess rewrites #527
Open
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.
Hello everyone,
this PR aims to address some of the issues that came up while working on the tracing delegate. Specifically, Princess will often rewrite formulas for operations like multiplication, divison or floor using quantifiers and epsilon terms. As an example let's take the formula
RationalFormulaManager.floor(RationalFormulamanager.makeNumber(0.5))
. Here Princess will produce the following expression:While the expression is logically equivalent, and solvers are allowed to make some rewrites, such a fundamental transformation makes is quite hard to understand the meaning of the term. More importantly, it will cause crashes in our visitor as epsilon terms are not supported by JavaSMT. Because of this many formulas in Princess currently can't be visited.
In this PR we try to fix the problem by translating Princess formulas back to their original operations. This is done by using pattern matching in the visitor: We first create a set of patterns by evaluating operations like
floor
or division on some generic arguments, f.exRationalFormulaManager.floor(a)
orRationalFormlaManager.divide(a, b)
wherea
,b
are variables. Then we match those patterns against the current formula in the visitor. If they can be unified the substitution is then used to recover the original arguments for the operation. We then visit the operation with the recovered arguments and skip any quantifiers or epsilon terms that Princess has createdThe number of patterns that are needed is relatively small and currently looks like this:
Note that for some operations we need several patterns to cover all cases. We should make sure that these patterns are indeed always enough to match the terms that Princess returns. However, from my experience the transformation that Princess applies is relatively static and the solver doesn't try to optimize these terms any further.
We could alternatively still ask the Princess developers to handle the back translation for us. However, I haven't opened an issue about this yet.