Closed shigoel closed 9 months ago
Here is an attempt to re-state the formula in terms of Std.BitVec.ult
and Std.BitVec.ule
to get around the issue:
theorem auto_bitvec_inequality_test_1 (i j max : Std.BitVec 64)
(h0 : Std.BitVec.ult i max) (h1 : Std.BitVec.ule j (max - i))
(h2 : Std.BitVec.ult 0#64 j) :
Std.BitVec.ult (max - (i + j)) (max - i) := by
auto
Unfortunately, auto ran for several minutes, and produced the following:
[auto.smt.result] z3 produces unexpected check-sat response |timeout|
However, when I independently submitted the SMT file to z3 (version 4.11.2 - 64 bit), it was solved in ~0.06s.
Generated SMT file:
(declare-sort |Empty| 0)
(define-fun |nsub| ((|x| |Int|) (|y| |Int|)) |Int| (|ite| (|>=| |x| |y|) (|-| |x| |y|) 0))
(define-fun |itdiv| ((|x| |Int|) (|y| |Int|)) |Int| (|ite| (|=| |y| 0) |x| (|ite| (|>=| |x| 0) (|div| |x| |y|) (|-| (|div| (|-| |x|) |y|)))))
(define-fun |itmod| ((|x| |Int|) (|y| |Int|)) |Int| (|ite| (|=| |y| 0) |x| (|ite| (|>=| |x| 0) (|mod| |x| |y|) (|-| (|mod| (|-| |x|) |y|)))))
(define-fun |iediv| ((|x| |Int|) (|y| |Int|)) |Int| (|ite| (|=| |y| 0) 0 (|div| |x| |y|)))
(define-fun |iemod| ((|x| |Int|) (|y| |Int|)) |Int| (|ite| (|=| |y| 0) |x| (|mod| |x| |y|)))
(declare-fun |smti_0| () (_ BitVec 64))
(declare-fun |smti_1| () (_ BitVec 64))
(assert (! (|=| (|bvult| |smti_0| |smti_1|) |true|) :named valid_fact_0))
(declare-fun |smti_2| () (_ BitVec 64))
(assert (! (|=| (|bvule| |smti_2| (|bvadd| |smti_1| (|bvneg| |smti_0|))) |true|) :named valid_fact_1))
(assert (! (|=| (|bvult| #b0000000000000000000000000000000000000000000000000000000000000000 |smti_2|) |true|) :named valid_fact_2))
(assert (! (|not| (|=| (|bvult| (|bvadd| |smti_1| (|bvneg| (|bvadd| |smti_0| |smti_2|))) (|bvadd| |smti_1| (|bvneg| |smti_0|))) |true|)) :named valid_fact_3))
I cannot reproduce [auto.smt.result] z3 produces unexpected check-sat response |timeout|
, and instead got a crash in the Lean server.
According to the behaviour of lean-auto
on my machine, there are three separate issues:
fun (a b : BitVec 64) => a <= b
is different from @Std.BitVec.ule 64
, so auto
does not recognize them as the same. To fix this, more simplification rules are needed. This is a more involved issue and I'll fix it later.auto.smt.rconsProof
to temporarily skip proof parsing, which should have no negative impact on the current behaviour of lean-auto.trace[auto.smt.result] ...{proof}...
causes Lean to crash, presumably because proof
is too long. I've splitted auto.smt.result
into auto.smt.result
, auto.smt.proof
and auto.smt.model
.Hopefully this will make the second example work on your machine.
Thank you, @PratherConid! Indeed, the second example (the one with Std.BitVec.ult
and Std.BitVec.ule
) does work for me after turning off proof
.
The following is a theorem, but worryingly,
auto
reported a counterexample.From the generated SMT commands (pasted in at the end of this message), one can see that the issue was that
<
and<=
were defined as uninterpreted SMT functions, and not in terms ofbvult
andbvule
, as I had expected.This was inconsistent with
+
and-
, which were indeed resolved tobvadd
andbvneg
.