-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Nikolaj Bjorner <[email protected]>
- Loading branch information
1 parent
a7b6f30
commit 0e6c645
Showing
2 changed files
with
32 additions
and
16 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
0e6c645
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When printing a solver state after pre-processing, the displayed solver state does not necessarily preserve models. To be able to reconstruct models of the original formula, z3 extends smtlib2 with model-add and model-del commands. For propositional clauses, model-add corresponds to a deleted clause with blocked literal. For example, if clause (a or b or c) is deleted and a is blocked, then it generates the (model-add a (or a (not (or b c)))) instruction.
Some of the pre-processing methods in z3 do not create a clean model-add/model-del command sequence (it is a legacy issue). It is possible for a pre-processing method to simply remove some symbols because they just occur in left side of equalities. The model converter for this case is just a "model" object. It was not printed with the model-add/model-del syntax and therefore the resulting SMTLIB2 solver state could not be parsed. This commit addresses this sub-case for model converter serialization.