[SMT-LIB] Draft of SMT-LIB 2.5: request for feedback
Adrien Champion
adrien.champion at email.com
Sat Sep 27 21:14:54 EDT 2014
Hi all,
Just to make sure we are all talking about the same thing.
My understanding is that using push/pop generally impacts performance as it switches the solver to an incremental mode far less efficient than the normal one --to allow backtracking when popping. To me, check-sat-assuming is/should be a way for SMT solver devs to support “efficient restricted incrementality”, a feature some us are expecting eagerly.
So if this is what check-sat-assuming is for, then my proposal is the following:
(check-sat-assuming (<command>*))
where <command> is in some subset of the SMT-LIB commands.
This set should be side-effect-free for the solver, i.e. should not include declare-fun define-fun…
It should allow get-unsat-core, get-model and get-value to be useable for model checking.
In any case, “More precisely, [check-sat-assuming] has the same effect as (push 1) … (pop 1)” page 54 seems to vague for me. Assuming what I said so far makes any sense, then:
“check-sat-assuming should be functionally equivalent to (push 1) … (pop 1). However, SMT-solver developers are encouraged to take advantage of this command to offer more efficient incremental satisfiability checks than the very permissive push/pop mechanism.”
English is not my native language, sorry if it is a bit cumbersome.
Also, apologies if my understanding is wrong :-)
Cheers,
Adrien
On Sep 27, 2014, at 6:44 PM, Jürgen Christ <christj at informatik.uni-freiburg.de> wrote:
>> The standardized get-model and check-sat-assuming look great, but I'm
>> concerned that you can't use them together. From the description of
>> check-sat-assuming on page 54:
>>
>> "Note that after the command executes the current context does not
>> contain the assumptions anymore; as a consequence, it is not
>> meaningful, and so not permitted, to call model inspection commands
>> such as get-model or get-assignment immediately after
>> check-sat-assuming."
>
> That seems very limiting. Why not remove check-sat-assuming and add an assume
> command and a clear-assumptions command? Then, we can simply declare both
> commands as modifications of the assertion stack and have a solution to the
> model problem.
>
>> In my case, I'm always interested in getting a model after a sat
>> result. So what would the workflow be like for me?
>>
>> (check-sat-assuming a1 ... an)
>> ;; Receive sat response
>> (push 1)
>> (assert a1 ... an)
>> (check-sat)
>> (get-model)
>> (pop 1)
>>
>> This feels cumbersome and I worry about the efficiency implications.
>> It would be nice if one could somehow inspect the model created via
>> check-sat-assuming, or at least have a command like
>> check-sat-assuming-and-get-model-if-sat. That's a bit tongue in cheek,
>> but you get the idea.
>
> My proposal:
>
> (assume a1 ... an)
> (check-sat)
> (get-model)
> (clear-assumptions)
>
> I see that an assume command raises the problem of "additive" assumptions like
> (assume a1 ... an)
> (check-sat)
> (assume b1 ... bm)
> (check-sat)
>
> But it should be easy to forbid that or implement it...
>
> At first glance I also found an inconsistency on page 43. The abstract values
> are not written using (as ...), but this syntax made it into the draft.
>
> Regards,
>
> Jürgen
>
> _______________________________________________
> SMT-LIB mailing list
> SMT-LIB at cs.nyu.edu
> http://www.cs.nyu.edu/mailman/listinfo/smt-lib
More information about the SMT-LIB
mailing list