formal-verification

问题 Given a proof of set inclusion and its converse I'd like to be able to show that two sets are equal. For example, I know how to prove the following statement, and its converse: open set universe u variable elem_type : Type u variable A : set elem_type variable B : set elem_type def set_deMorgan_incl : A ∩ B ⊆ set.compl ((set.compl A) ∪ (set.compl B)) := sorry Given these two inclusion proofs, how do I prove set equality, i.e. def set_deMorgan_eq : A ∩ B = set.compl ((set.compl A) ∪ (set.compl

问题 I came across the terms "concrete & symbolic execution" when I was going through the concept of concolic testing. (The article mentioned there, "CUTE: A concolic unit testing engine for C" , uses that term in its abstract section.) "The approach used builds on previous work combining symbolic and concrete execution, and more specifically, using such a combination to generate test inputs to explore all feasible execution paths." Can anyone please confirm what "concrete execution" means? In

问题 Here, http://spinroot.com/spin/Man/Manual.html, it is written that: In Promela there is also another way to avoid the test and set problem: atomic sequences. By prefixing a sequence of statements enclosed in curly braces with the keyword atomic the user can indicate that the sequence is to be executed as one indivisible unit, non-interleaved with any other processes. It causes a run-time error if any statement, other than the first statement, blocks in an atomic sequence . This is how we can

问题 The theorem proving tool z3 is taking a lot of time to solve a formula, which I believe it should be able to handle easily. To understand this better and possibly optimize my input to z3, I wanted to see the internal constraints that z3 generates as part of its solving process. How do I print the formula that z3 produces for its back-end solvers, when using z3 from the command line? 回答1: Z3 command line tool does not have such option. Moreover, Z3 contains several solvers and pre-processing

问题 UPDATED Problems on solving some dafny problems, described below with the given class and respective methods. If you need something else please tell me, thank you in advance. Also the link is updated with all this code in rise4fun. class TextEdit { var text:array<char>; //conteúdo var scrap: array<char>; //conteúdo temporariamente guardado para copy/paste var tlen:int; //length di text var slen:int; //length di scrap var at:int; //current position var sellen:int; //length of the selection

问题 I'm working my way through the chapter 4 of the lean tutorial. I'd like to be able to prove simple equalities, such as a = b → a + 1 = b + 1 without having to use the calc environment. In other words I'd like to explicitly construct the proof term of: example (a b : nat) (H1 : a = b) : a + 1 = b + 1 := sorry My best guess is that I need to use eq.subst and some relevant lemma about equality on natural numbers from the standard library, but I'm at loss. The closest lean example I can find is

问题 I'm looking at doing some verification work where I've got regular tree grammars as an underlying theory. Z3 lets you define your own stuff with uninterpreted functions, but that doesn't tend to work well any time your decision procedures are recursive. They used to allow for plugins but that has been depricated, I think. I'm wondering, does anybody have a recommendation of a decent SMT solver that allows you to write decision procedures for custom theories? 回答1: There are several options

问题 What tools exist to help one to experiment with weakly ordered concurrency? That is, in what sandbox can one play while teaching oneself about partial fences, weak atomics, acquire/consume/release semantics, lock-free algorithms and the like? The tool or sandbox one wants would exercise and stress one's weakly ordered, threaded algorithm, exposing the various ways in which the algorithm might theoretically fail. Physically running on an x86, for example, the tool would nevertheless be able to

问题 I was thinking about the fact that we can prove a program has bugs. We can test it to assess that it is more or less bug resistant. But is there a way (even theoretically) to prove that a program has no bug ? For simple programs, such as a "Hello World", I guess we should be able to do it. But what about larger programs ? 回答1: There are nowadays many different formalisms that can be used to prove programs correct (e.g., formalizations in proof assistants, dependently typed programming

问题 I'm trying to understand inductive types from chapter 7 of "theorem proving in lean". I set myself a task of proving that successor of natural numbers has a substitution property over equality: inductive natural : Type | zero : natural | succ : natural -> natural lemma succ_over_equality (a b : natural) (H : a = b) : (natural.succ a) = (natural.succ b) := sorry After some guesswork and fairly exhaustive search I was able to satisfy the compiler with a couple of possibilities: lemma succ_over