You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand that this is a bit of nit-picking. While z3 is not compliant to SMT-Lib spec in the above sense, I can also see that you forgo the undecidable termination checking and simply assume all recursive-equations are well-defined. But looks like you already have the mechanisms to at least "detect" such cases in certain circumstances, so I wonder why the discrepancy between define-fun-rec and the semantically equivalent forall variant. In particular, while looping-forever is never nice, it's better than having an unsound model returned; from the perspective of tools that use z3 as a backend.
I'm perfectly happy this being marked as "won't-fix", though perhaps it is worthy of a mention in the user-guide or documentation somewhere.
The text was updated successfully, but these errors were encountered:
I am aware of this behavior. It is mentioned somewhere else before.
non-terminating recursive definitions -> unsound results.
Often unsoundness is the other way around: return unsat when the problem is sat.
Should z3 establish termination when it returns SAT?
Maybe. But currently, model-validation is naive and just loops.
A reason to not spending bandwidth on non-termination checking was to assume ITP or "auto-active" users handle this at their level: why replicate what first-class methods for termination and non-termination accomplish (some of which use z3 for solving sub-problems)?
SMT-Lib recursive function definitions are given semantics via quantified formulas for the defining equations. Hence, I'd expect:
to produce
unsat
sincef
is not satisfiable by any functionInt -> Int
. Indeedcvc5
producesunsat
for this query. But z3 says:This model is bogus. Indeed:
Surprisingly, if I replace
define-fun-rec
with:then z3 does say
unsat
correctly.I understand that this is a bit of nit-picking. While z3 is not compliant to SMT-Lib spec in the above sense, I can also see that you forgo the undecidable termination checking and simply assume all recursive-equations are well-defined. But looks like you already have the mechanisms to at least "detect" such cases in certain circumstances, so I wonder why the discrepancy between
define-fun-rec
and the semantically equivalentforall
variant. In particular, while looping-forever is never nice, it's better than having an unsound model returned; from the perspective of tools that use z3 as a backend.I'm perfectly happy this being marked as "won't-fix", though perhaps it is worthy of a mention in the user-guide or documentation somewhere.
The text was updated successfully, but these errors were encountered: