disable e-matching by default, adding option to turn it on #4
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.
We've been working on a model that produces queries that cause Z3 to diverge. On a hunch, I tried running the same
.smt2
query with Z3's e-matching quantifier-instantiation strategy disabled, and it now returns a result in a (relatively) timely fashion.If I understand correctly, checking formulas in FAU should really never be using e-matching anyways, right? Or is it supposed to be harmless to have it turned on anyways, and just assume it doesn't get used (or only gets used in an interleaved fashion with MBQI, or something)? Anyway, it appears to risk divergence to have it turned on, at least in some cases!
(Interestingly, this only works if I also run ivy with
incremental=false
, which I do not really understand the effects of in terms of quantifier instantiation -- or any other bit of Z3 internals -- but it at least does work then!)