Proof Systems

There are formal proof systems that could be divided into two groups: (1) proof assistants (sometimes called proof checkers like Mizar1 _{[Try80, Rud92, MR05], Is-}

abelle2 _{[NPW02], Coq}3 _{[Log06, BC04], etc.), and (2) theorem provers (like Boyer-}

Moore4 _{[KB95], PVS}5 _{[ORS92], Vampire}6 _{[Vor95, RV02], etc.). Each proof system}

provides its own formal language for writing mathematics based on some founda- tion of logic and mathematics.

The very first project of computer support for formal mathematics representa- tion and automated verification dates back to 1967. At that time N.G. de Bruijn initiated an Automath[dB80, vD80] (AUTOmating MATHematics) project aimed at designing a language for expressing complete mathematical theories in such a way that a computer can verify the correctness[vBJ77]. Automath supported automated checking of full correctness of a mathematical document written in Automath’s formal language. Six years later around 1973-74, independently and without the knowledge of the existing Automath project, A. Trybulec has started a project called Mizar. The vision was to develop a computerised assistance in the process of editing mathematical papers. The main aims of the early years of that project were:

1. to form a basis for the construction of an automated information system for mathematics,

2. to facilitate the detection of errors, the verification of references, the elimi- nation of repeated theories, etc.,

1 http://www.mizar.org 2 http://isabelle.in.tum.de 3 http://coq.inria.fr 4 http://www.cs.utexas.edu/users/moore/best-ideas/nqthm/ 5 http://pvs.csl.sri.com/ 6 http://www.voronkov.com/vampire.cgi

3. to open a way to a machine assisted education of the art of proving theories, 4. to enable the automated generation of input into typesetting systems. We discuss in more details the Mizar system in Section 3.

Since then, many proof systems have been built to mechanically check logic, mathematics or software (e.g., Coq, Nuprl, Isabelle, Otter etc.). Generally these systems support checking full correctness of mathematical theories.

Unfortunately, along with the number advantages of using proof systems there are number of disadvantages. The main disadvantage is the enormous expense of formalisation using any of the existing proof systems. Let us explain briefly what causes this issue. First of all a mathematician wanting to build a formalisation needs to decide which proof system he wants to use for writing and verifying the logic of a document. At this point he is obliged to build a formal document within the language and the logic foundation supported by the chosen software. This is already a very labor intensive job. First of all, because it requires an expert knowledge to the underlined logic and the syntax of the language interpreted by the chosen proof system. Second of all, most proof systems have no meaningful support for the common mathematical language. In most cases the language used to build formalisation for a specific proof system differs greatly from CML. The rigid structure and rules of a formal document created within any proof systems make the language of the formal system much more closer to a computer programming language than to a natural language. In many cases it has nothing common with a natural language. A notable exception is Mizar, which however requires the use of natural language in a rigid and inflexible way. The Mizar formalised version of a mathematical document is human readable and resembles the CML, although it still looks like a computer programming language.

Listings 2.4 and 2.5 present the formalisation of a CML document from Fig- ure 2.2 within two formal systems: Mizar and Coq, respectively.

t h e o r e m :: Phytagoras ’ t h e o r e m sqrt 2 is i r r a t i o n a l

proof

assume sqrt 2 is r a t i o n a l;

then c o n s i d e r a , b being I n t e g e r such that

A1 : b <> 0 and

A2 : sqrt 2 = a / b and

A3 : a gcd b = 1 by L o c a l _ T H 2; A4 : b ^2 <> 0 by A1 , S Q U A R E _ 1 :73; 0 <= 2 by NAT_1 :18; then

2 = ( a / b )^2 by A2 , S Q U A R E _ 1:def 4 .= a ^2/ b ^2 by S Q U A R E _ 1 :69;

then A6 : a ^2 = 2* b ^2 by A4 , X C M P L X _ 1 :88;

then a ^2 is even by ABIAN :def 1;

then a is even by P Y T H T R I P :2;

then c o n s i d e r c being I n t e g e r such that

A8 : a = 2* c by ABIAN :def 1; A9 : 4* c ^2 = (2*2)* c ^2 .= 2^2* c ^2 by S Q U A R E _ 1:def 3 .= 2* b ^2 by A8 , S Q U A R E _ 1 :68 , A6 ; 2*(2* c ^2) = (2*2)* c ^2 .= 2* b ^2 by A9 ; then 2* c ^2 = b ^2 by X C M P L X _ 1 :5;

then b ^2 is even by ABIAN :def 1;

then b is even by P Y T H T R I P :2;

then ex j being I n t e g e r st b = 2* j by ABIAN :def 1;

then 2 d i v i d e s a & 2 d i v i d e s b by A8 , INT_1 :def 9;

then A11 : 2 d i v i d e s a gcd b by INT_2 :33; a gcd b = 1 by A3 , INT_2 :def 4;

hence c o n t r a d i c t i o n by A11 , INT_2 :17;

end;

Listing 2.4: A part of a Mizar proof of the example of Figure 2.2 The Mizar version of the proof, inspired by F. Wiedijk’s one from [Wie06].

All in all, a formalisation process using any of the proof systems, in smaller or bigger level, is similar/could be compared with writing a computer program where a proof system language corresponds to a “programming language” and the proof system itself, plays the role of a “compiler”. As a result of these disadvantages, mathematicians are required to possess some computer programming knowledge. This extended knowledge is too domain specific and totally unnecessary for the or- dinary mathematician. Therefore, ordinary mathematicians are usually not willing to spend the effort to formalise their own work in a proof system.

Going farther, mathematics written on a piece of paper has many of “justifica- tion holes” and “hints” which are left for the reader’s intuition. Mathematicians assume that some of their justifications are obvious or require a very little effort or depend on straightforward reasoning. Hence, they tend not to include obvious proofs in their papers and at the same time make the paper clear and concise in its structure and logical reasoning. This of course depends on an individual math- ematicians style of writing mathematics. When mathematics is written in a formal language of a chosen proof system, those “justification holes” and “hints”, as well

as any obvious inferences that are left implicit , have to be made explicit within a formal document. Proof systems have no “human mind intelligence” to understand those implicit justifications while checking the logical correctness of a document. Therefore any implicit information in a document needs to be made explicit within a formalised representation of the document within a chosen proof system.

A proof system can check the logical correctness of a document only if it is sufficiently detailed for the software. As a result, the formalisation of mathematics becomes even more labour intensive and tedious for a mathematician. Moreover the formalisation of a document is not as clear or as concise as the original paper- printed version of the mathematical document.

Theorem i r r a t i o n a l R s q r t 2: ( irrational ( sqrt ( S ( S O )))).

Red.

Intros p q H ; Red; Intros H0 ; Case H .

Apply ( main_thm p ).

86 Replace ( Div2 . double ( mult q q )) with ( mult ( S ( S O )) ( mult q q )); [Idtac | Unfold Div2 . double ; Ring ].

Case ( Peano_dec . eq_nat_dec ( mult p p ) ( mult ( S ( S O )) ( mult q q ))) ; Auto;

Intros H1 .

Case ( not_nm_INR ? ? H1 ); Repeat Rewrite mult_INR . 91 Rewrite <- ( sqrt_def ( INR ( S ( S O )))); Auto with real .

Rewrite R a b s o l u _ r i g h t in H0 ; Auto with real .

Rewrite H0 ; Auto with real .

Cut ~ <R > q == R0 ; [Intros H2 ; Field | Idtac]; Auto with real .

Apply Rle_ge ; Apply Rlt_le ; Apply sqrt_lt_R 0 ; Auto with real . 96 Qed.

Listing 2.5: A part of a Coq proof of the example of Figure 2.2. The above code in Coq is a “declarative approach” of the presentation of the CML document. Part of Laurent Th´ery’s Coq proof from F. Wiedijk’s [Wie06].