-
Notifications
You must be signed in to change notification settings - Fork 56
Solver independent interpolation #560
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
base: master
Are you sure you want to change the base?
Changes from all commits
733d43b
8d35e69
eab70d4
4d77924
e2119ad
f9d735c
8f87aec
a4769a4
993f400
c256db9
d78e284
23ae59a
2404f5c
05864d6
a8eb472
9d74f92
a3e98de
a587a83
70ccc55
d20c5f8
a29d671
74424f6
89acfea
6d7d488
2fa4562
56168b4
788b408
52e6134
e4f245c
316b747
4b04456
995fa72
d2601d6
82b5d78
02ce3f3
9abf0e0
2bfbe5d
64c13db
a4fd707
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -53,7 +53,37 @@ enum ProverOptions { | |
| GENERATE_UNSAT_CORE_OVER_ASSUMPTIONS, | ||
|
|
||
| /** Whether the solver should enable support for formulae build in SL theory. */ | ||
| ENABLE_SEPARATION_LOGIC | ||
| ENABLE_SEPARATION_LOGIC, | ||
|
|
||
| /** | ||
| * Enables Craig interpolation, using the model-based interpolation strategy. This strategy | ||
| * constructs interpolants based on the model provided by a solver, i.e. model generation must | ||
| * be enabled. This interpolation strategy is only usable for solvers supporting quantified | ||
| * solving over the theories interpolated upon. The solver does not need to support | ||
| * interpolation itself. | ||
| */ | ||
| GENERATE_PROJECTION_BASED_INTERPOLANTS, | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It might not be a good idea to add options that are only relevant for interpolating provers to the general
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added this as a quick dummy. Hence the question about how we want to do it properly ;D |
||
|
|
||
| /** | ||
| * Enables (uniform) Craig interpolation, using the quantifier-based interpolation strategy | ||
| * utilizing quantifier-elimination in the forward direction. Forward means, that the set of | ||
| * formulas A, used to interpolate, interpolates towards the set of formulas B (B == all | ||
| * formulas that are currently asserted, but not in the given set of formulas A used to | ||
| * interpolate). This interpolation strategy is only usable for solvers supporting | ||
| * quantifier-elimination over the theories interpolated upon. The solver does not need to | ||
| * support interpolation itself. | ||
| */ | ||
| GENERATE_UNIFORM_FORWARD_INTERPOLANTS, | ||
|
|
||
| /** | ||
| * Enables (uniform) Craig interpolation, using the quantifier-based interpolation strategy | ||
| * utilizing quantifier-elimination in the backward direction. Backward means, that the set of | ||
| * formulas B (B == all formulas that are currently asserted, but not in the given set of | ||
| * formulas A used to interpolate) interpolates towards the set of formulas A. This | ||
| * interpolation strategy is only usable for solvers supporting quantifier-elimination over the | ||
| * theories interpolated upon. The solver does not need to support interpolation itself. | ||
| */ | ||
| GENERATE_UNIFORM_BACKWARD_INTERPOLANTS | ||
| } | ||
|
|
||
| /** | ||
|
|
@@ -68,7 +98,6 @@ enum ProverOptions { | |
| /** | ||
| * Create a fresh new {@link InterpolatingProverEnvironment} which encapsulates an assertion stack | ||
| * and allows generating and retrieve interpolants for unsatisfiable formulas. If the SMT solver | ||
| * is able to handle satisfiability tests with assumptions please consider implementing the {@link | ||
| * InterpolatingProverEnvironment} interface, and return an Object of this type here. | ||
| * | ||
| * @param options Options specified for the prover environment. All the options specified in | ||
|
|
||
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.
@kfriedberger @PhilippWendler do you guys have feedback/ideas/proposals for how we want the user to be able to switch in between native and solver independent interpolation techniques? Currently we just
ProverOptions, which is not ideal, as they can't be switched once a prover has been created.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.
Why would I want to switch the interpolation implementation for a prover instance and why would it be a problem to create a new prover instance instead? I don't really see a use case.
What I am interested in is to have the following 3 possibilities:
The third method could be done by catching the exception from the first case, but why not let JavaSMT provide it as well for the benefit of all its users?
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.
OK that seems reasonable.
I thought it might be good to decide about a interpolation technique when asking for interpolants, as users can implement point 3 themselves (potentially even with more than one fallback.
Also interpolation is (usually) only possible after UNSAT has been returned. If a user wants to generate interpolants with multiple techniques in sequence, that would not be possible. E.g.: start with a technique like projection based interpolants that tends to return interpolants fast, but they also tend to be weak -> then use a stronger technique if that first interpolant is not useful. In your approach, a user would need to build a second (or n) new provers and then check satisfiability again.
(Just some thoughts. I want to provide the best possible API. I don't have a preference at the moment.)
@leventeBajczi you also use interpolation, maybe you have some thoughts?
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.
I don't really have any further input to this -- as long as it's clear how I'm getting the interpolants, I don't mind if I need to create separate solver instances. We would probably always use point 3 if it was available, especially if it also handled the case when a solver returns an error for the interpolation query (although I'm not sure if the resulting solver state always stays usable). Failing that, we already have some support for using a portfolio of solvers, so we could easily implement the switching ourselves.