Closed shmarovfedor closed 10 years ago
Thanks, Fedor. I fixed the bug in b231f9622d76b42719ae955b59a585d2f4c32ba0
Thank you for fixing it so quickly!
Paolo
Is it also possible to modify the tool to support more complex invariants (conjunctions and disjunctions of simple terms)?
Yes, it's certainly possible. Currently, it's handled by extract_invariant
function in ode_solver.cpp
, which only supports simple inequalities. In general, we can even call the ICP solver recursively and check almost arbitrary (ODE-free) mode invariants.
That's great. Thank you
Supporting more complex formulas requires recursive call to the solver itself. This leads to general algorithms for solving exists-forall formulas which can be widely useful. It's a significant step and will take some time. @shmarovfedor would you be interested in working with us on that?
Fedor and I were just discussing this morning how to use exists-forall formulas for parameter estimation and synthesis. We should start working on this now!
Paolo
From: Sicun Gao [mailto:notifications@github.com] Sent: 20 June 2014 17:53 To: dreal/dreal Cc: Paolo Zuliani Subject: Re: [dreal] Invariant bug (#49)
Supporting more complex formulas requires recursive call to the solver itself. This leads to general algorithms for solving exists-forall formulas which can be widely useful. It's a significant step and will take some time. @shmarovfedorhttps://github.com/shmarovfedor would you be interested in working with us on that?
— Reply to this email directly or view it on GitHubhttps://github.com/dreal/dreal/issues/49#issuecomment-46701109.
@pzuliani Great! I'll sketch some notes after CMSB :)
Has there been any movement on this issue regarding generalized invariants? I think I'll need it for some new encodings that I want to develop.
I plan to work on the in December (have algorithms, need to implement). What do your invariants look like? (linear, polynomial, ...?)
On Oct 28, 2014, at 19:15, Daniel Bryce notifications@github.com wrote:
Has there been any movement on this issue regarding generalized invariants? I think I'll need it for some new encodings that I want to develop.
— Reply to this email directly or view it on GitHub.
Arbitrary Boolean function with propositional and nonlinear literals. However, there are no integrals or quantifiers. See my latest draft in the silver-surfer repo.
On Oct 28, 2014, at 1:30 PM, Sicun Gao notifications@github.com wrote:
I plan to work on the in December (have algorithms, need to implement). What do your invariants look like? (linear, polynomial, ...?)
On Oct 28, 2014, at 19:15, Daniel Bryce notifications@github.com wrote:
Has there been any movement on this issue regarding generalized invariants? I think I'll need it for some new encodings that I want to develop.
— Reply to this email directly or view it on GitHub. — Reply to this email directly or view it on GitHub.
That's the sort of stuff we would also like to have :)
It's my last week at MSR. I'll work on non-ODE part until the mid November. After that, I plan to revisit the ODE part.
Here are a few examples of invariant conditions I’m looking at (from http://www.aaai.org/Papers/JAIR/Vol27/JAIR-2708.pdf, page 289):
(and (< (demand) (supply)) (day)) (> (demand) (supply)) (day) (not (day)) (not (and (day) (>= (daytime) (dusk)))) (not (and (not (day)) (>= (daytime) 0))) (> (soc) (safelevel))
As you can see, they are not super complicated, but mix standard Boolean operators and propositional and numeric literals. I believe that the propositional literals can be checked once because they won’t change over an interval, just at the boundaries. In these examples, the only change needed for dReal is to allow simple inequalities on other variables (and not just constants).
The numeric literals can be more complicated than I show here. The syntax for these conditions follows the syntax for
For this we'll need dReal to call itself. Let's talk about it in the next meeting.
Both following problems should be UNSAT. In the first case I obtain the correct result
The result is
The following problem is SAT (which is incorrect) but I just swapped 2 invariants in conjunction:
The result:
Is it also possible to modify the tool to support more complex invariants (conjunctions and disjunctions of simple terms)?