Skip to content
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

Support for activation literals #20

Open
rachitnigam opened this issue Jun 9, 2023 · 5 comments
Open

Support for activation literals #20

rachitnigam opened this issue Jun 9, 2023 · 5 comments

Comments

@rachitnigam
Copy link
Contributor

Not sure if this is goal for this library but it might be useful to implement activation literals in the same way that the rsmt2 library does. In practice, they are a much more efficient alternative to push and pop since the latter force SMT solvers to reset a bunch of internal state and disable incremental solving which can be useful for subsequent queries.

@elliottt
Copy link
Owner

elliottt commented Jun 9, 2023

That's a neat idea! I'm not sure it's an explicit goal for the library -- originally it started as a rust implementation of the haskell simple-smt library, whose goal was to provide a uniform api for the smt-lib interface that many solvers provide. I think that supporting activation literals is the sort of thing that could be built on top of easy-smt, perhaps we could include a module that would help manage that state for those that would like to use them?

@rachitnigam
Copy link
Contributor Author

Yup! That’s exactly how rsmt2 does it as well. I have a use case for it so might try implementing it. One nice thing in this library is since everything is interned, there might be a cleaner, simpler abstraction to support path dependent/activation literal-based asserts

elliottt pushed a commit that referenced this issue Aug 15, 2023
Implements `check-sat-assuming` and reimplements `check-sat` as a
special case of that. The former is useful because often times it lets
you get away with not having to use `push` and `pop` (and in fact needed
to implement #20).
@aur3l14no
Copy link

the latter force SMT solvers to reset a bunch of internal state and disable incremental solving which can be useful for subsequent queries.

@rachitnigam I thought push/pop can still preserve internal state. Can you provide some evidence/source for this? Thanks!

@rachitnigam
Copy link
Contributor Author

Normally solvers need to reset lots of state and disable various tactics that are not compatible with "incremental solving" (which is what push and pop require).

@aur3l14no
Copy link

aur3l14no commented Nov 5, 2023

Yeah I know the latter half, but not the former. I think I'll rephrase my question to: what are the internal states that get reset in push/pop mode and not get reset in check-sat-assuming mode? For example, I thought the lemma learned before the corresponding push would be preserved. But maybe I was wrong? Or maybe this is more solver-specific and even solver-config-specific, which is gonna be very tricky. Could you share some info on these details?

Background: I have an application that requires incremental solving and have been using push/pops. I do find that under certain options, it is not quite "incremental" as I expect it to be. For example, vars irrelevant to new assertions whose constraints sit at the bottom of the assertion stack seem to be re-calculated every time I check. I think the actlit technique you propose here looks really promising and I will definitely try it out. So thanks for the info. :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants