Logic, Checking, and Proving - moodle.risc.jku.at

Logic, Checking, and Proving

Wolfgang [email protected]

Research Institute for Symbolic Computation (RISC)Johannes Kepler University, Linz, Austria

http://www.risc.jku.at

Wolfgang Schreiner http://www.risc.jku.at 1/67

1. The Language of Logic

2. The RISC Algorithm Language

3. The Art of Proving

4. The RISC ProofNavigator


The Language of Logic

Two kinds of syntactic phrases.Term T denoting an object.

Variable xObject constant cFunction application f (T1, . . . ,Tn) (may be written in�x)

n-ary function constant f

Formula F denoting a truth value.Atomic formula p(T1, . . . ,Tn) (may be written in�x)

n-ary predicate constant p.

Negation ¬F (�not F �)Conjunction F1 ∧ F2 (�F1 and F2�)Disjunction F1 ∨ F2 (�F1 or F2�)Implication F1 ⇒ F2 (�if F1, then F2�)Equivalence F1 ⇔ F2 (�if F1, then F2, and vice versa�)Universal quanti�cation ∀x : F (�for all x , F �)Existential quanti�cation ∃x : F (�for some x , F �)


Syntactic Shortcuts

∀x1, . . . , xn : F

∀x1 : . . . : ∀xn : F

∃x1, . . . , xn : F

∃x1 : . . . : ∃xn : F

∀x ∈ S : F

∀x : x ∈ S ⇒ F

∃x ∈ S : F

∃x : x ∈ S ∧ F

Help to make formulas more readable.


Examples

Terms and formulas may appear in various syntactic forms.

Terms:

exp(x)a · b + 1a[i ] · b√

x2+2x+1

(y+1)2

Formulas:

a2 + b2 = c2

n | 2n∀x ∈ N : x ≥ 0∀x ∈ N : 2|x ∨ 2|(x + 1)∀x ∈ N, y ∈ N : x < y ⇒∃z ∈ N : x + z = y

Terms and formulas may be nested arbitrarily deeply.


The Meaning of Formulas

Atomic formula p(T1, . . . ,Tn)True if the predicate denoted by p holds for the values of T1, . . . ,Tn.

Negation ¬FTrue if and only if F is false.

Conjunction F1 ∧ F2 (�F1 and F2�)True if and only if F1 and F2 are both true.

Disjunction F1 ∨ F2 (�F1 or F2�)True if and only if at least one of F1 or F2 is true.

Implication F1 ⇒ F2 (�if F1, then F2�)False if and only if F1 is true and F2 is false.

Equivalence F1 ⇔ F2 (�if F1, then F2, and vice versa�)True if and only if F1 and F2 are both true or both false.

Universal quanti�cation ∀x : F (�for all x , F �)True if and only if F is true for every possible value assignment of x .

Existential quanti�cation ∃x : F (�for some x , F �)True if and only if F is true for at least one value assignment of x .


Example

We assume the domain of natural numbers and the �classical�interpretation of constants 1, 2, +, =, <.

1+ 1 = 2True.

1+ 1 = 2 ∨ 2+ 2 = 2True.

1+ 1 = 2 ∧ 2+ 2 = 2False.

1+ 1 = 2⇒ 2 = 1+ 1True.

1+ 1 = 1⇒ 2+ 2 = 2True.

1+ 1 = 2⇒ 2+ 2 = 2False.

1+ 1 = 1⇔ 2+ 2 = 2True.


Example

x + 1 = 1+ xTrue, for every assignment of a number a to variable x .

∀x : x + 1 = 1+ xTrue (because for every assignment a to x , x + 1 = 1+ x is true).

x + 1 = 2If x is assigned �one�, the formula is true.If x is assigned �two�, the formula is false.

∃x : x + 1 = 2True (because x + 1 = 2 is true for assignment �one� to x).

∀x : x + 1 = 2False (because x + 1 = 2 is false for assignment �two� to x).

∀x : ∃y : x < yTrue (because for every assignment a to x , there exists theassignment a+ 1 to y which makes x < y true).

∃y : ∀x : x < yFalse (because for every assignment a to y , there is the assignmenta+ 1 to x which makes x < y false).


Formula Equivalences

Formulas may be replaced by equivalent formulas.

¬¬F1 ! F1

¬(F1 ∧ F2) ! ¬F1 ∨ ¬F2¬(F1 ∨ F2) ! ¬F1 ∧ ¬F2¬(F1 ⇒ F2) ! F1 ∧ ¬F2¬∀x : F ! ∃x : ¬F¬∃x : F ! ∀x : ¬FF1 ⇒ F2 ! ¬F2 ⇒ ¬F1F1 ⇒ F2 ! ¬F1 ∨ F2

F1 ⇔ F2 ! ¬F1 ⇔ ¬F2. . .

Familiarity with manipulation of formulas is important.


Example

�All swans are white or black.�∀x : swan(x)⇒ white(x) ∨ black(x)

�There exists a black swan.�∃x : swan(x) ∧ black(x).

�A swan is white, unless it is black.�∀x : swan(x) ∧ ¬black(x)⇒ white(x)∀x : swan(x) ∧ ¬white(x)⇒ black(x)∀x : swan(x)⇒ white(x) ∨ black(x)

�Not everything that is white or black is a swan.�¬∀x : white(x) ∨ black(x)⇒ swan(x).∃x : (white(x) ∨ black(x)) ∧ ¬swan(x).

�Black swans have at least one black parent�.∀x : swan(x) ∧ black(x)⇒ ∃y : swan(y) ∧ black(y) ∧ parent(y , x)

It is important to recognize the logical structure of an informal sentencein its various equivalent forms.


The Usage of Formulas

Precise formulation of statements describing object relationships.

Statement:

If x and y are natural numbers and y is not zero, then q is thetruncated quotient of x divided by y .

Formula:

x ∈ N ∧ y ∈ N ∧ y 6= 0⇒q ∈ N ∧ ∃r ∈ N : x = y · q + r ∧ r < y

Problem speci�cation:

Given natural numbers x and y such that y is not zero, computethe truncated quotient q of x divided by y .

Inputs: x , yInput condition: x ∈ N ∧ y ∈ N ∧ y 6= 0Output: qOutput condition: q ∈ N ∧ ∃r ∈ N : x = y · q + r ∧ r < y


Problem Speci�cations

The speci�cation of a computation problem:Input: variables x1 ∈ S1, . . . , xn ∈ SnInput condition (�precondition�): formula I (x1, . . . , xn).Output: variables y1 ∈ T1, . . . , ym ∈ Tn

Output condition (�postcondition�): O(x1, . . . , xn, y1, . . . , ym).F (x1, . . . , xn): only x1, . . . , xn are free in formula F .x is free in F , if not every occurrence of x is inside the scope of aquanti�er (such as ∀ or ∃) that binds x .

An implementation of the speci�cation:A function (program) f : S1 × . . .× Sn → T1 × . . .× Tm such that

∀x1 ∈ S1, . . . , xn ∈ Sn : I (x1, . . . , xn)⇒let (y1, . . . , ym) = f (x1, . . . , xn) in

O(x1, . . . , xn, y1, . . . , ym)

For all arguments that satisfy the input condition, f must computeresults that satisfy the output condition.

Basis of all speci�cation formalisms.Wolfgang Schreiner http://www.risc.jku.at 12/67

Example: A Problem Speci�cation

Given an integer array a, a position p in a, and a length l , return the arrayb derived from a by removing a[p], . . . , a[p + l − 1].

Input: a ∈ Z∗, p ∈ N, l ∈ NInput condition:

p + l ≤ length(a)

Output: b ∈ Z∗

Output condition:let n = length(a) in

length(b) = n − l ∧(∀i ∈ N : i < p ⇒ b[i ] = a[i ]) ∧(∀i ∈ N : p ≤ i < n − l ⇒ b[i ] = a[i + l ])

Mathematical theory:

T ∗ :=⋃

i∈N T i ,T i := Ni → T ,Ni := {n ∈ N : n < i}length : T ∗ → N, length(a) = such i ∈ N : a ∈ T i


Validating Problem Speci�cations

Do formal input condition I (x) and output condition O(x , y) reallycapture our informal intentions?

Do concrete inputs/output satisfy/violate these conditions?I (a1), ¬I (a2), O(a1, b1), ¬O(a1, b2).

Is input condition satis�able?∃x : I (x).

Is input condition not trivial?∃x : ¬I (x).

Is output condition satis�able for every input?∀x : I (x)⇒ ∃y : O(x , y).

Is output condition for all (at least some) inputs not trivial?∀x : I (x)⇒ ∃y : ¬O(x , y).∃x : I (x) ∧ ∃y : ¬O(x , y).

Is for every legal input at most one output legal?∀x : I (x)⇒ ∀y1, y2 : O(x , y1) ∧ O(x , y2)⇒ y1 = y2.

Validate speci�cation to increase our con�dence in its meaning!Wolfgang Schreiner http://www.risc.jku.at 14/67






The RISC Algorithm Language (RISCAL)

A system for formally specifying and checking algorithms.Research Institute for Symbolic Computation (RISC), 2016�.

http://www.risc.jku.at/research/formal/software/RISCAL.

Implemented in Java with SWT library for the GUI.Tested under Linux only; freely available as open source (GPL3).

A language for the de�ning mathematical theories and algorithms.A static type system with only �nite types (of parameterized sizes).Predicates, explicitly (also recursively) and implicitly def.d functions.Theorems (universally quanti�ed predicates expected to be true).Procedures (also recursively de�ned).Pre- and post-conditions, invariants, termination measures.

A framework for evaluating/executing all de�nitions.Model checking: predicates, functions, theorems, procedures,annotations may be evaluated/executed for all possible inputs.All paths of a non-deterministic execution may be elaborated.The execution/evaluation may be visualized.

Validating algorithms by automatically verifying �nite approximations.Wolfgang Schreiner http://www.risc.jku.at 16/67

The RISC Algorithm Language (RISCAL)

RISCAL divide.txt &


Using RISCAL

See also the (printed/online) �Tutorial and Reference Manual�.

Press button (or <Ctrl>-s) to save speci�cation.Automatically processes (parses and type-checks) speci�cation.

Press button to re-process speci�cation.

Choose values for unde�ned constants in speci�cation.Natural number for val const: N.Default Value: used if no other value is speci�ed.Other Values: speci�c values for individual constants.

Select Operation from menu and then press button .Executes operation for chosen constant values and all possible inputs.Option Silent: result of operation is not printed.Option Nondeterminism: all execution paths are taken.Option Multi-threaded: multiple threads execute di�erent inputs.Press buttton to abort execution.

During evaluation all annotations (pre/postconditions, etc.) are checked.Wolfgang Schreiner http://www.risc.jku.at 18/67

Typing Mathematical Symbols

ASCII String Unicode CharacterInt ZNat N:= :=true >false ⊥~ ¬/\ ∧\/ ∨=> ⇒<=> ⇔forall ∀exists ∃sum

∑product

∏

ASCII String Unicode Character~= 6=<= ≤>= ≥* ·times ×{} ∅intersect ∩union ∪Intersect

⋂Union

⋃isin ∈subseteq ⊆<< 〈>> 〉

Type the ASCII string and press <Ctrl>-# to get the Unicode character.


Example: Quotient and Remainder

Given natural numbers n and m, we want to compute the quotient q andremainder r of n divided by m.

// the type of natural numbers less than equal N

val N: N;type Num = N[N];

// the precondition of the computation

pred pre(n:Num, m:Num) ⇔ m 6= 0;

// the postcondition, first formulation

pred post1(n:Num, m:Num, q:Num, r:Num) ⇔n = m·q + r ∧∀q0:Num, r0:Num.

n = m·q0 + r0 ⇒ r ≤ r0;

// the postcondition, second formulation

pred post2(n:Num, m:Num, q:Num, r:Num) ⇔n = m·q + r ∧ r < m;

We will investigate this speci�cation.Wolfgang Schreiner http://www.risc.jku.at 20/67


// for all inputs that satisfy the precondition

// both formulations are equivalent:

// ∀n:Num, m:Num, q:Num, r:Num.

// pre(n, m) ⇒ (post1(n, m, q, r) ⇔ post2(n, m, q, r));

theorem postEquiv(n:Num, m:Num, q:Num, r:Num)

requires pre(n, m);

⇔ post1(n, m, q, r) ⇔ post2(n, m, q, r);

// we will thus use the simpler formulation from now on

pred post(n:Num, m:Num, q:Num, r:Num) ⇔ post2(n, m, q, r);

Check equivalence for all values that satisfy the precondition.



Choose e.g. value 5 for N.

Switch option Silent o�:Executing postEquiv(Z,Z,Z,Z) with all 1296 inputs.

Ignoring inadmissible inputs...

Run 6 of deterministic function postEquiv(0,1,0,0):

Result (0 ms): true


Result (0 ms): true

...


Result (0 ms): true

Execution completed for ALL inputs (6314 ms, 1080 checked, 216 inadmissible).

Switch option Silent on:Executing postEquiv(Z,Z,Z,Z) with all 1296 inputs.


If theorem is false for some input, an error message is displayed.



Drop precondition from theorem.

theorem postEquiv(n:Num, m:Num, q:Num, r:Num) ⇔// requires pre(n, m);

post1(n, m, q, r) ⇔ post2(n, m, q, r);

Executing postEquiv(Z,Z,Z,Z) with all 1296 inputs.


ERROR in execution of postEquiv(0,0,0,0): evaluation of

postEquiv

at line 25 in file divide.txt:

theorem is not true

ERROR encountered in execution.

For n = 0,m = 0, q = 0, r = 0, the modi�ed theorem is not true.


Visualizing the Formula Evaluation

Select N = 1 and visualization option �Tree�.

Investigate the (pruned) evaluation tree to determine how the truth valueof a formula was derived (double click to zoom into/out of predicates).



Switch option �Nondeterminism� on.// 1. investigate whether the specified input/output combinations are as desired

fun quotremFun(n:Num, m:Num): Tuple[Num,Num]

requires pre(n, m);

= choose q:Num, r:Num with post(n, m, q, r);

Executing quotremFun(Z,Z) with all 36 inputs.


Branch 0:6 of nondeterministic function quotremFun(0,1):

Result (0 ms): [0,0]


No more results (8 ms).

...




No more results (14 ms).


First validation by inspecting the values determined by output condition(nondeterminism may produce for some inputs multiple outputs).



// 2. check that some but not all inputs are allowed

theorem someInput() ⇔ ∃n:Num, m:Num. pre(n, m);

theorem notEveryInput() ⇔ ∃n:Num, m:Num. ¬pre(n, m);

Executing someInput().

Execution completed (0 ms).

Executing notEveryInput().

Execution completed (0 ms).

A very rough validation of the input condition.



// 3. check whether for all inputs that satisfy the precondition

// there are some outputs that satisfy the postcondition

theorem someOutput(n:Num, m:Num)

requires pre(n, m);

⇔ ∃q:Num, r:Num. post(n, m, q, r);

// 4. check that not every output satisfies the postcondition

theorem notEveryOutput(n:Num, m:Num)

requires pre(n, m);

⇔ ∃q:Num, r:Num. ¬post(n, m, q, r);

Executing someOutput(Z,Z) with all 36 inputs.


Executing notEveryOutput(Z,Z) with all 36 inputs.


A very rough validation of the output condition.



// 5. check that the output is uniquely defined

// (optional, need not generally be the case)

theorem uniqueOutput(n:Num, m:Num)

requires pre(n, m);

⇔∀q:Num, r:Num. post(n, m, q, r) ⇒∀q0:Num, r0:Num. post(n, m, q0, r0) ⇒q = q0 ∧ r = r0;

Executing uniqueOutput(Z,Z) with all 36 inputs.


The output condition indeed determines the outputs uniquely.



// 6. check whether the algorithm satisfies the specification

proc quotRemProc(n:Num, m:Num): Tuple[Num,Num]

requires pre(n, m);

ensures let q=result.1, r=result.2 in post(n, m, q, r);

{

var q: Num = 0;

var r: Num = n;

while r ≥ m do

{

r := r-m;

q := q+1;

}

return 〈q,r〉;}

Check whether the algorithm satis�es the speci�cation.



Executing quotRemProc(Z,Z) with all 36 inputs.


Run 6 of deterministic function quotRemProc(0,1):




...












A veri�cation of the algorithm by checking all possible executions.



proc quotRemProc(n:Num, m:Num): Tuple[Num,Num]

requires pre(n, m);

ensures post(n, m, result.1, result.2);

{

var q: Num = 0;

var r: Num = n;

while r > m do // error!

{

r := r-m;

q := q+1;

}

return 〈q,r〉;}

Executing quotRemProc(Z,Z) with all 36 inputs.

ERROR in execution of quotRemProc(1,1): evaluation of

ensures let q = result.1, r = result.2 in post(n, m, q, r);

at line 65 in file divide.txt:

postcondition is violated by result [0,1]

ERROR encountered in execution.

A falsi�caton of an incorrect algorithm.Wolfgang Schreiner http://www.risc.jku.at 31/67

Example: Sorting an Array

val N:Nat; val M:Nat;

type nat = Nat[M]; type array = Array[N,nat]; type index = Nat[N-1];

proc sort(a:array): array

ensures ∀i:nat. i < N-1 ⇒ result[i] ≤ result[i+1];

ensures ∃p:Array[N,index].(∀i:index,j:index. i 6= j ⇒ p[i] 6= p[j]) ∧(∀i:index. a[i] = result[p[i]]);

{

var b:array = a;

for var i:Nat[N]:=1; i<N; i:=i+1 do {

var x:nat := b[i];

var j:Int[-1,N] := i-1;

while j ≥ 0 ∧ b[j] > x do {

b[j+1] := b[j];

j := j-1;

}

b[j+1] := x;

}

return b;

}



Using N=5.

Using M=5.

Type checking and translation completed.

Executing sort(Array[Z]) with all 7776 inputs.

1223 inputs (1223 checked, 0 inadmissible, 0 ignored)...


...











Not all nondeterministic branches may have been considered.

Also this algorithm can be automatically checked.



Select operation sort and press the button �Show/Hide Tasks�.

Automatically generated formulas to validate procedure speci�cations.Wolfgang Schreiner http://www.risc.jku.at 34/67


Right-click to print de�nition of a formula, double-click to check it.

For every input, is postcondition true for only one output?

theorem _sort_0_PostUnique(a:array) ⇔∀result:array with

(∀i:index. ((i < (N-1)) ⇒ (result[i] ≤ result[i+1]))) ∧(∃p:Array[N,index]. ((∀i:index, j:index. ((i 6= j) ⇒ (p[i] 6= p[j]))) ∧(∀i:index. (a[i] = result[p[i]])))).

(∀_result:array with let result = _result in #

((∀i:index. ((i < (N-1)) ⇒ (result[i] ≤ result[i+1]))) ∧(∃p:Array[N,index]. ((∀i:index, j:index. ((i 6= j) ⇒ (p[i] 6= p[j]))) ∧(∀i:index. (a[i] = result[p[i]]))))).

(result = _result));

Using N=3.

Using M=3.

Type checking and translation completed.

Executing _sort_0_PostUnique(Array[Z]) with all 64 inputs.


The output is indeed uniquely de�ned by the output condition.Wolfgang Schreiner http://www.risc.jku.at 35/67

Model Checking versus Proving

Two fundamental techniques for the veri�cation of computer programs.

Checking Program Executions

Enumeration of all possible executions and evaluation of formulas(e.g. postconditions) on the resulting states.Fully automatic, no human interaction is required.Only possible if there are only �nitely many executions (and �nitelymany values for the quanti�ed variables in the formulas).State space explosion: ��nitely many� means �not too many�.

Proving Veri�cation Conditions

Logic formulas that are valid if and only if program is correct withrespect to its speci�cation.Also possible if there are in�nitely many excutions and in�nitely manyvalues for the quanti�ed variables.Many conditions can be automatically proved (automated reasoners);in general interaction with human is required (proof assistants).

General veri�cation requires the proving of logic formulas.Wolfgang Schreiner http://www.risc.jku.at 36/67






Proofs

A proof is a structured argument that a formula is true.

A tree whose nodes represent proof situations (states).

• • • •↖ ↗ ↖ ↗

• •↖ ↗

•Each proof situation consists of knowledge and a goal.

• K1, . . . ,Kn ` G

Knowledge K1, . . . ,Kn: formulas assumed to be true.Goal G : formula to be proved relative to knowledge.

The root of the tree is the initial proof situation.

K1, . . . ,Kn: axioms of mathematical background theories.G : formula to be proved.


Proof Rules

A proof rules describes how a proof situation can be reduced to zero, one,or more �subsituations�.

. . . ` . . . . . . ` . . .K1, . . . ,Kn ` G

Rule may or may not close the (sub)proof:

Zero subsituations: G has been proved, (sub)proof is closed.One or more subsituations: G is proved, if all subgoals are proved.

Top-down rules: focus on G .

G is decomposed into simpler goals G1,G2, . . .

Bottom-up rules: focus on K1, . . . ,Kn.

Knowledge is extended to K1, . . . ,Kn,Kn+1.

In each proof situation, we aim at showing that the goal is �apparently�true with respect to the given knowledge.


Conjunction F1 ∧ F2

K ` G1 K ` G2

K ` G1 ∧ G2

. . . ,K1 ∧ K2,K1,K2 ` G. . . ,K1 ∧ K2 ` G

Goal G1 ∧ G2.

Create two subsituations with goals G1 and G2.

We have to show G1 ∧ G2.

We show G1: . . . (proof continues with goal G1)We show G2: . . . (proof continues with goal G2)

Knowledge K1 ∧ K2.

Create one subsituation with K1 and K2 in knowledge.

We know K1 ∧ K2. We thus also know K1 and K2.(proof continues with current goal and additionalknowledge K1 and K2)


Disjunction F1 ∨ F2

K ,¬G1 ` G2

K ` G1 ∨ G2

. . . ,K1 ` G . . . ,K2 ` G. . . ,K1 ∨ K2 ` G

Goal G1 ∨ G2.Create one subsituation where G2 is proved under the assumptionthat G1 does not hold (or vice versa):

We have to show G1 ∨ G2. We assume ¬G1 and show G2.(proof continues with goal G2 and additional knowledge¬G1)

Knowledge K1 ∨ K2.Create two subsituations, one with K1 and one with K2 in knowledge.

We know K1 ∨ K2. We thus proceed by case distinction:

Case K1: . . . (proof continues with current goal and additionalknowledge K1).Case K2: . . . (proof continues with current goal and additional

knowledge K2).


Implication F1 ⇒ F2

K ,G1 ` G2

K ` G1 ⇒ G2

. . . ` K1 . . . ,K2 ` G. . . ,K1 ⇒ K2 ` G

Goal G1 ⇒ G2

Create one subsituation where G2 is proved under the assumptionthat G1 holds:

We have to show G1 ⇒ G2. We assume G1 and show G2.(proof continues with goal G2 and additional knowledge G1)

Knowledge K1 ⇒ K2

Create two subsituations, one with goal K1 and one withknowledge K2.

We know K1 ⇒ K2.

We show K1: . . . (proof continues with goal K1)We know K2: . . . (proof continues with current goal and

additional knowledge K2).


Equivalence F1 ⇔ F2

K ` G1 ⇒ G2 K ` G2 ⇒ G1

K ` G1 ⇔ G2

. . . ` (¬)K1 . . . , (¬)K2 ` G

. . . ,K1 ⇔ K2 ` G

Goal G1 ⇔ G2

Create two subsituations with implications in both directions as goals:

We have to show G1 ⇔ G2.

We show G1 ⇒ G2: . . . (proof continues with goal G1 ⇒ G2)We show G2 ⇒ G1: . . . (proof continues with goal G2 ⇒ G1)

Knowledge K1 ⇔ K2

Create two subsituations, one with goal (¬)K1 and one withknowledge (¬)K2 .

We know K1 ⇔ K2.

We show (¬)K1: . . . (proof continues with goal (¬)K1)We know (¬)K2: . . . (proof continues with current goal and

additional knowledge (¬)K2)


Universal Quanti�cation ∀x : F

K ` G [x0/x ]

K ` ∀x : G(x0 new for K ,G)

. . . ,∀x : K ,K [T/x ] ` G

. . . ,∀x : K ` G

Goal ∀x : G

Introduce new (arbitrarily named) constant x0 and create onesubsituation with goal G [x0/x ].

We have to show ∀x : G . Take arbitrary x0.We show G [x0/x ]. (proof continues with goal G [x0/x ])

Knowledge ∀x : K

Choose term T to create one subsituation with formula K [T/x ]added to the knowledge.

We know ∀x : K and thus also K [T/x ].(proof continues with current goal and additionalknowledge K [T/x ])


Existential Quanti�cation ∃x : F

K ` G [T/x ]

K ` ∃x : G

. . . ,K [x0/x ] ` G

. . . ,∃x : K ` G(x0 new for K ,G)

Goal ∃x : G

Choose term T to create one subsituation with goal G [T/x ].

We have to show ∃x : G . It su�ces to show G [T/x ].(proof continues with goal G [T/x ])

Knowledge ∃x : K

Introduce new (arbitrarily named constant) x0 and create onesubsituation with additional knowledge K [x0/x ].

We know ∃x : K . Let x0 be such that K [x0/x ].(proof continues with current goal and additionalknowledge K [x0/x ])


Example

We show

(a) (∃x : ∀y : P(x , y)) ⇒ (∀y : ∃x : P(x , y))

We assume

(1) ∃x : ∀y : P(x , y)

and show

(b) ∀y : ∃x : P(x , y)

Take arbitrary y0. We show

(c) ∃x : P(x , y0)

From (1) we know for some x0

(2) ∀y : P(x0, y)

From (2) we know

(3) P(x0, y0)

From (3), we know (c). QED.


Example

We show

(a) (∃x : p(x)) ∧ (∀x : p(x) ⇒ ∃y : q(x , y)) ⇒ (∃x , y : q(x , y))

We assume

(1) (∃x : p(x)) ∧ (∀x : p(x) ⇒ ∃y : q(x , y))

and show

(b) ∃x , y : q(x , y)

From (1), we know

(2) ∃x : p(x)(3) ∀x : p(x) ⇒ ∃y : q(x , y)


(4) p(x0)

. . .


Example (Contd)

. . .

From (3), we know

(5) p(x0) ⇒ ∃y : q(x0, y)

From (4) and (5), we know

(6) ∃y : q(x0, y)

From (6), we know for some y0

(7) q(x0, y0)

From (7), we know (b). QED.


Indirect Proofs

K ,¬G ` false

K ` GK ,¬G ` F K ,¬G ` ¬F

K ` G. . . ,¬G ` ¬K. . . ,K ` G

Add ¬G to the knowledge and show a contradiction.

Prove that �false� is true.Prove that a formula F is true and also prove that it is false.Prove that some knowledge K is false, i.e. that ¬K is true.

Switches goal G and knowledge K (negating both).

Sometimes simpler than a direct proof.


Example

We show

(a) (∃x : ∀y : P(x , y)) ⇒ (∀y : ∃x : P(x , y))

We assume

(1) ∃x : ∀y : P(x , y)

and show

(b) ∀y : ∃x : P(x , y)

We assume

(2) ¬∀y : ∃x : P(x , y)

and show a contradiction.. . .


Example

. . .

From (2), we know

(3) ∃y : ∀x : ¬P(x , y)

Let y0 be such that

(4) ∀x : ¬P(x , y0)


(5) ∀y : P(x0, y)

From (5) we know

(6) P(x0, y0)

From (4), we know

(7) ¬P(x0, y0)

From (6) and (7), we have a contradiction. QED.







The RISC ProofNavigator

An interactive proving assistant for program veri�cation.Research Institute for Symbolic Computation (RISC), 2005�.

http://www.risc.jku.at/research/formal/software/ProofNavigator.

Development based on prior experience with PVS (SRI, 1993�).Kernel and GUI implemented in Java.Uses external SMT (satis�ability modulo theories) solver.

CVCL (Cooperating Validity Checker Lite) 2.0, CVC3, CVC4 1.4.

Runs under Linux (only); freely available as open source (GPL).

A language for the de�nition of logical theories.Based on a strongly typed higher-order logic (with subtypes).Introduction of types, constants, functions, predicates.

Computer support for the construction of proofs.Commands for basic inference rules and combinations of such rules.Applied interactively within a sequent calculus framework.Top-down elaboration of proof trees.

Designed for simplicity of use; applied to non-trivial veri�cations.Wolfgang Schreiner http://www.risc.jku.at 53/67

Using the Software

For survey, see �Program Veri�cation with the RISC ProofNavigator�. Fordetails, see �The RISC ProofNavigator: Tutorial and Manual�.

Develop a theory.Text �le with declarations of types, constants, functions, predicates.Axioms (propositions assumed true) and formulas (to be proved).

Load the theory.File is read; declarations are parsed and type-checked.Type-checking conditions are generated and proved.

Prove the formulas in the theory.Human-guided top-down elaboration of proof tree.Steps are recorded for later replay of proof.Proof status is recorded as �open� or �completed�.

Modify theory and repeat above steps.Software maintains dependencies of declarations and proofs.Proofs whose dependencies have changed are tagged as �untrusted�.


Starting the Software

Starting the software:module load ProofNavigator (users at RISC)ProofNavigator &

Command line options:Usage: ProofNavigator [OPTION]... [FILE]

FILE: name of file to be read on startup.

OPTION: one of the following options:

-n, --nogui: use command line interface.

-c, --context NAME: use subdir NAME to store context.

--cvcl PATH: PATH refers to executable "cvcl".

-s, --silent: omit startup message.

-h, --help: print this message.

Repository stored in subdirectory of current working directory:ProofNavigator/

Option -c dir or command newcontext "dir " :

Switches to repository in directory dir.


The Graphical User Interface


A Theory

% switch repository to "sum"

newcontext "sum";

% the recursive definition of the sum from 0 to n

sum: NAT->NAT;

S1: AXIOM sum(0)=0;

S2: AXIOM FORALL(n:NAT): n>0 => sum(n)=n+sum(n-1);

% proof that explicit form is equivalent to recursive definition

S: FORMULA FORALL(n:NAT): sum(n) = (n+1)*n/2;

Declarations written with an external editor in a text �le.


Proving a Formula

When the �le is loaded, the declarations are pretty-printed:

The proof of a formula is started by the prove command.


Proving a Formula


Proving a Formula

Proof of formula F is represented as a tree.Each tree node denotes a proof state (goal).

Logical sequent:A1,A2, . . . ` B1,B2, . . ..Interpretation:(A1 ∧ A2 ∧ . . .) ⇒ (B1 ∨ B2 ∨ . . .)

Initially single node Axioms ` F .

Constants: x0 ∈ S0, . . .[L1] A1

. . .[Ln] An

[Ln+1] B1

. . .[Ln+m] Bm

The tree must be expanded to completion.Every leaf must denote an obviously valid formula.

Some Ai is false or some Bj is true.

A proof step consists of the application of a proving rule to a goal.

Either the goal is recognized as true.Or the goal becomes the parent of a number of children (subgoals).

The conjunction of the subgoals implies the parent goal.


An Open Proof Tree

Closed goals are indicated in blue; goals that are open (or have opensubgoals) are indicated in red. The red bar denotes the �current� goal.


A Completed Proof Tree

The visual representation of the complete proof structure; by clicking on anode, the corresponding proof state is displayed.


Navigation Commands

Various buttons support navigation in a proof tree.

: prev

Go to previous open state in proof tree.

: next

Go to next open state in proof tree.

: undo

Undo the proof command that was issued in the parent of the currentstate; this discards the whole proof tree rooted in the parent.

: redo

Redo the proof command that was previously issued in the currentstate but later undone; this restores the discarded proof tree.

Single click on a node in the proof tree displays the corresponding state;double click makes this state the current one.


Proving Commands

The most important proving commands can be also triggered by buttons.

(scatter)Recursively applies decomposition rules to the current proof state andto all generated child states; attempts to close the generated statesby the application of a validity checker.

(decompose)Like scatter but generates a single child state only (no branching).

(split)Splits current state into multiple children states by applying rule tocurrent goal formula (or a selected formula).

(auto)Attempts to close current state by instantiation of quanti�ed formulas.

(autostar)Attempts to close current state and its siblings by instantiation.

Automatic decomposition of proofs and closing of proof states.Wolfgang Schreiner http://www.risc.jku.at 64/67

Proving Commands

More commands can be selected from the menus.assume

Introduce a new assumption in the current state; generates a siblingstate where this assumption has to be proved.

case:Split current state by a formula which is assumed as true in one childstate and as false in the other.

expand:Expand the de�nitions of denoted constants, functions, or predicates.

lemma:Introduce another (previously proved) formula as new knowledge.

instantiate:Instantiate a universal assumption or an existential goal.

induction:Start an induction proof on a goal formula that is universallyquanti�ed over the natural numbers.

Here the creativity of the user is required!Wolfgang Schreiner http://www.risc.jku.at 65/67

Auxiliary Commands

Some buttons have no command counterparts.

: counterexample

Generate a �counterexample� for the current proof state, i.e. aninterpretation of the constants that refutes the current goal.

Abort current prover activity (proof state simpli�cation orcounterexample generation).

Show menu that lists all commands and their (optional) arguments.

Simplify current state (if automatic simpli�cation is switched o�).

More facilities for proof control.


Proving Strategies

Initially: semi-automatic proof decomposition.

expand expands constant, function, and predicate de�nitions.scatter aggressively decomposes a proof into subproofs.decompose simpli�es a proof state without branching.induction for proofs over the natural numbers.

Later: critical hints given by user.

assume and case cut proof states by conditions.instantiate provide speci�c formula instantiations.

Finally: simple proof states are yielded that can be automaticallyclosed by the validity checker.

auto and autostar may help to close formulas by the heuristicinstantiation of quanti�ed formulas.

Appropriate combination of semi-automatic proof decomposition, criticalhints given by the user, and the application of a validity checker is crucial.


Documents

Logic, Checking, and Proving - moodle.risc.jku.at