-
Notifications
You must be signed in to change notification settings - Fork 251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Quantifier instantiation via simplistic E-matching #8224
base: develop
Are you sure you want to change the base?
Quantifier instantiation via simplistic E-matching #8224
Conversation
Despite this being a "draft" PR I would like to ask for feedback on the following aspects:
|
e08d98e
to
24806af
Compare
24806af
to
69f8720
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #8224 +/- ##
========================================
Coverage 79.64% 79.65%
========================================
Files 1684 1684
Lines 195661 195714 +53
========================================
+ Hits 155837 155893 +56
+ Misses 39824 39821 -3 ☔ View full report in Codecov by Sentry. |
6e48e44
to
49b3909
Compare
7bb221f
to
64252a0
Compare
64252a0
to
d821caa
Compare
conjunction(...) and disjunction(...) helper functions produce the appropriate result for empty operand sequences.
d821caa
to
090c84a
Compare
This is now done, comment explaining the (expected) verification failure is now included. |
Use E-matching on index expressions to instantiate quantifiers when eager instantiation (aka enumerative instantiation) cannot be applied.
090c84a
to
72550cf
Compare
This needs serious consideration: failing quantifier instantiation is the leading source of proof brittleness, and we are opening the door to that here. |
I would much prefer a more deterministic, predictable and robust solution to this. |
Hard maybe? So, it would be good but there is going to be a limit on how much we can do like this. Unless we put a refinement loop around the solver and do something like MBQI. Getting that stable and reliable is tricky. Given the amount of work that has gone into E-matching in Z3 and Andy's decade+ of work on quantifiers in cvc5, I wonder whether it would be more efficient (in terms of dev-hours / things proved) to improve our SMT integration. To actually answer the question you asked, things that might help:
HTH |
Use E-matching on index expressions to instantiate quantifiers when eager instantiation (aka enumerative instantiation) cannot be applied.