Les assistants de preuve ou comment avoir confiance en ses ......Du bug `a la preuve Les assistants...

Post on 06-Jun-2020

0 views 0 download

Transcript of Les assistants de preuve ou comment avoir confiance en ses ......Du bug `a la preuve Les assistants...

Du bug a la preuveLes assistants de preuve ou comment avoir confiance en ses

demonstrations.

Julien Narboux

Conference ISN, Avril 2015

Table des matieres1 Le probleme

2 TypageTypage statique vs dynamiqueHoare’s “billion-dollard mistake”

3 TestGeneralitesTest unitaires

4 Preuve de programmesApproche preuve du programme originalApproche par extraction

5 Les assistants de preuveQuelques succesQui verifie le verificateur ?Automatisation

6 Curry-Howard

7 Un exemple en geometrie

8 Conclusion

Exemples de bugs fameux

Ariane Vol 501 (1996)

”The software exception wascaused during execution of a dataconversion from 64-bit floatingpoint to 16-bit signed integervalue. The floating point numberwhich was converted had a valuegreater than what could berepresented by a 16-bit signedinteger. [...] The value was muchhigher than expected because theearly part of the trajectory ofAriane 5 di↵ers from that of Ariane4 and results in considerably higherhorizontal velocity values.”

Ariane 501 Inquiry Board report:http://esamultimedia.esa.int/docs/esa-x-1819eng.pdf

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 3 / 92

Mars Climate Orbiter (1999)

”The ’root cause’ of the loss of thespacecraft was the failedtranslation of English units intometric units in a segment ofground-based, navigation-relatedmission software.”

Cout : $327 600 000.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 4 / 92

Exemple introductif1

int abs(int x)

{

int z;

if (x<0)

z=-x;

else

z=x;

return z;

}

Ce programme est faux !

Si x = �231, 231 n’existe pas.

1

Source: David Mentre

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 5 / 92

Exemple introductif1

int abs(int x)

{

int z;

if (x<0)

z=-x;

else

z=x;

return z;

}

Ce programme est faux !

Si x = �231, 231 n’existe pas.

1

Source: David Mentre

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 5 / 92

Premieres idees

Tester quelques exemples

On ecrit une fonction:Programme + Propriete ! Vrai/Faux

Tester toutes les branches possibles.

Problemes:On ne peut pas tester tous les cas.

Les Heisenbug: L’Heisenbug est un bug qui disparaıt quand on essaiede l’etudier. Par exemple une condition de concurrence (racecondition) quand le programme est en mode debuggage peutdisparaıtre.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 6 / 92

Premieres idees

Tester quelques exemples

On ecrit une fonction:Programme + Propriete ! Vrai/Faux

Tester toutes les branches possibles.

Problemes:On ne peut pas tester tous les cas.

Les Heisenbug: L’Heisenbug est un bug qui disparaıt quand on essaiede l’etudier. Par exemple une condition de concurrence (racecondition) quand le programme est en mode debuggage peutdisparaıtre.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 6 / 92

Solution ? un logiciel pour trouver tous les bugs ?

Probleme de l’arretIl n’existe pas de programme permettant de decider si un programmetermine ou pas.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 7 / 92

Premiere approche

On reduit la classe des proprietes que l’on va verifier.

Exemple

pas de probleme de type: langages fortement types (Ocaml, Haskell,Scala, . . . )

Exemple

pas de ”plantage”: division par zero, ou acces en dehors des tableaux(Airbus A380)

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 8 / 92

Deuxieme solution (complementaire)

On fait la preuve que le programme verifie ses specifications. Unraisonnement fini pour traiter une infinite de cas.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 9 / 92

Ce que l’on souhaite verifier

1 Terminaison

2 Comportement: le programme fait ce qu’il est cense faire.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 10 / 92

Comment obtenir des programmes moins bugues ?

1 Typage

2 Test

3 Preuve

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 11 / 92

Table des matieres1 Le probleme

2 TypageTypage statique vs dynamiqueHoare’s “billion-dollard mistake”

3 TestGeneralitesTest unitaires

4 Preuve de programmesApproche preuve du programme originalApproche par extraction

5 Les assistants de preuveQuelques succesQui verifie le verificateur ?Automatisation

6 Curry-Howard

7 Un exemple en geometrie

8 Conclusion

Typage

Empecher des operations impossibles:

1+"toto"

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 13 / 92

Typage statique/dynamique

Typage statique

Le typage est calcule a lacompilation.

Typage dynamique

Le typage est verifie a l’execution.

Exemples

Ada, C, C++, C#, Ocaml,Haskell, Java, . . .

Exemples

Python, PHP, Javascript, Perl, . . .

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 14 / 92

Inconvenient du typage dynamique

Moins d’erreurs sont capturees a la compilation, plus de bugs peuventarriver a l’execution.

Le typage doit etre fait a l’execution, cela peut rendre le programmemoins e�cace.

Avantage du typage dynamique

Le typage dynamique facilite l’introspection.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 15 / 92

Exemple I

En Ocamllet f x y = x + z;;

Error: Unbound value z

En Python

>>> def f(x,y): return (x+z)

Et un jour :

f(3,5)

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

File "<stdin>", line 2, in f

NameError: global name ’z’ is not defined

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 16 / 92

Exemple II

En Ocaml# let f x = if x > 0 then "toto" else 5 + "titi";;

Error: This expression has type string but an expression was expected of type

int

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 17 / 92

Exemple II

En Python

def f(x):

if x > 0:

print ’Toto’

else:

print 5 + ’Titi’

Un jour :

File "essai.py", line 13, in f

print 5 + ’Titi’

TypeError: unsupported operand type(s) for +: ’int’ and ’str’

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 18 / 92

Un outil

Faire des verifications statiquement meme en Python:http://pychecker.sourceforge.net/ (fonctionne sur le premierexemple mais pas sur le deuxieme)

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 19 / 92

Tony Hoare (1934-)

Chercheur chez MicrosoftResearch

Prix Turing

Quicksort

CSP

Logique de Hoare, Anaxiomatic basis forcomputer programming(1969)

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 20 / 92

Hoare’s “billion-dollard mistake”

I call it my billion-dollar mistake. It was the invention of thenull reference in 1965. At that time, I was designing the firstcomprehensive type system for references in an object orientedlanguage (ALGOL W). My goal was to ensure that all use ofreferences should be absolutely safe, with checking performedautomatically by the compiler. But I couldn’t resist thetemptation to put in a null reference, simply because it was soeasy to implement. This has led to innumerable errors,vulnerabilities, and system crashes, which have probably caused abillion dollars of pain and damage in the last forty years. In recentyears, a number of program analysers like PREfix and PREfast inMicrosoft have been used to check references, and give warningsif there is a risk they may be non-null. More recent programminglanguages like Spec# have introduced declarations for non-nullreferences. This is the solution, which I rejected in 1965.

C.A.R. Hoarehttp://www.infoq.com/presentations/

Null-References-The-Billion-Dollar-Mistake-Tony-HoareJulien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 21 / 92

Explication du probleme

Image myimage = loadPicture(filename);

if (myimage != NULL) {

....

}

Il est di�cile de distinguer les pointeurs qui peuvent etre NULL deceux qui ne peuvent pas.

Il est facile d’oublier une verification.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 22 / 92

La solution ?

Se faire aider par le systeme de type en utilisant un type option

En Ocamltype ’a option =

Some of ’a

| None

C’est aussi disponible en: Haskell, Java � 8; Scala, Spec# (mais pas C#),Swift, . . .

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 23 / 92

Table des matieres1 Le probleme

2 TypageTypage statique vs dynamiqueHoare’s “billion-dollard mistake”

3 TestGeneralitesTest unitaires

4 Preuve de programmesApproche preuve du programme originalApproche par extraction

5 Les assistants de preuveQuelques succesQui verifie le verificateur ?Automatisation

6 Curry-Howard

7 Un exemple en geometrie

8 Conclusion

Cycle en V

Licence CC, auteur:Christophe Moustier

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 25 / 92

Tests: classement par niveau de detail

Tests unitaires Test des unites de programme de facon isolee:uniquement correction fonctionnelle.

Tests d’integration Test de la composition des modules via leur interface:principalement correction fonctionnelle.

Tests de validation Test du produit fini par rapport au cahier des charges:conformite, robustesse, securite, performance.

Recette Test du produit fini par le client.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 26 / 92

Processus de test

Les tests peuvent etre ecrits:

avant, (developpement guide par le test, test driven development)

pendant ou

apres

le code.

Les tests peuvent etre realises:

par le developpeur (tests unitaires)

par une equipe dediee

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 27 / 92

Aparte: Proposition Pedagogique

Demander aux eleves de garder les tests:

Cela fait partie du travail.

Il faudra surement les reutiliser.

Demander aux eleves d’ecrire les tests avant le code:

Cela les oblige a lire et comprendre l’enonce.

C’est une forme de documentation dans le cas d’un travail en groupe.

Exemple

print (longueur([1,2,3]) == 3)

print (longueur([]) == 0)

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 28 / 92

Oracle

Le test est realise vis a vis d’un comportement attendu. Celui-ci peut etredefini par:

des specifications

une norme

des contrats (preconditions, postconditions)

des versions precedentes

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 29 / 92

Tests unitaires

Principe:

Test des unites de programme de facon isolee, a l’ echelle de la classe oude la fonction. Pour chaque classe on cree une classe de test avec aumoins une methode de test par methode.

En pratique:1 Des annotations pour preciser quelles sont les fonctions de test et

d’initialisation des tests (quand le langage le permet).

2 Des assertions pour tester des proprietes: un predicat + un messaged’erreur.

3 Des lanceurs de tests: une boucle un peu evoluee.

4 Une interface graphique qui a�che les tests qui echouent apreschaque compilation.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 30 / 92

Exemples

Python pytest

Java junit

.Net nunit, xunit

haskell hunit

ocaml ounit

. . . a

a

http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 31 / 92

Exemple en Java: Junit

Annotations@Test designe les methodes de test

@Before executee avant chaque test (fixture)

@After executee apres chaque test

@BeforeClass executee avant tous les tests de la classe

@AfterClass executee apres tous les tests de la classe

@Ignore desactive un test

@Test (expected = Exception.class) permet de specifier qu’un teste doitlever une exception

@Test(timeout=100) permet de limiter le temps de calcul

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 32 / 92

AssertionsLes assertions permettent d’exprimer quand le test passe ou echoue.

assertsEquals([String message], expected, actual)

assertSame([String], expected, actual)

assertNotNull([message], object)

fail(String)

. . .

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 33 / 92

Exemple

pub l i c c l a s s Jun i tTe s t 1 {

p r i v a t e Co l l e c t i o n<St r i ng> c o l l e c t i o n ;

@Be fo r eC l a s s

pub l i c s t a t i c vo id a v an tC l a s s ( ) {System . out . p r i n t l n ( ” @Be fo r eC l a s s ” ) ;

}

@Af t e rC l a s s

pub l i c s t a t i c vo id a p r e sC l a s s e ( ) {System . out . p r i n t l n ( ” @A f t e rC l a s s ” ) ;

}

@Before

pub l i c vo id setUp ( ) {c o l l e c t i o n = new Ar r a yL i s t<St r i ng >();

c o l l e c t i o n . add ( ”Toto” ) ;

System . out . p r i n t l n ( ”@Before ” ) ;

}

@Afte r

pub l i c vo id tearDown ( ) {c o l l e c t i o n . c l e a r ( ) ;

System . out . p r i n t l n ( ”@Afte r ” ) ;

}

@Test

pub l i c vo id t e s t C o l l e c t i o n I n i t i a l e ( ) {a s s e r tT r u e ( c o l l e c t i o n . s i z e ()==1);

System . out . p r i n t l n ( ”@Test � c o l l e c t i o n i n i t i a l e ” ) ;

}

@Test

pub l i c vo id t e s tA jou tUn I t em ( ) {c o l l e c t i o n . add ( ” T i t i ” ) ;

a s s e r t E q u a l s (2 , c o l l e c t i o n . s i z e ( ) ) ;

System . out . p r i n t l n ( ”@Test � a j o u t d ’ un i tem” ) ;

}}

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 34 / 92

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 35 / 92

Table des matieres1 Le probleme

2 TypageTypage statique vs dynamiqueHoare’s “billion-dollard mistake”

3 TestGeneralitesTest unitaires

4 Preuve de programmesApproche preuve du programme originalApproche par extraction

5 Les assistants de preuveQuelques succesQui verifie le verificateur ?Automatisation

6 Curry-Howard

7 Un exemple en geometrie

8 Conclusion

Preuve de programmes

Plusieurs approches possibles

En prouvant le programme original

En generant un programme prouve:preuve de programmes fonctionnelspar extraction depuis Coqmethode B: par ra�nement depuis la specification. . .

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 37 / 92

Recherche dichotomique

int low = 0;

int high = a.length - 1;

while (low <= high) {

int mid = (low + high) / 2;

int midVal = a[mid];

if (midVal < key)

low = mid + 1

else if (midVal > key)

high = mid - 1;

else

return mid; // key found

}

return -(low + 1); // key not found.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 38 / 92

Pre/post conditions

Pre condition: formule logique exprimant les pre-suppositions d’unprogramme.

Post condition: formule logique indiquant les garanties fournies parun programme.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 39 / 92

Specifications

Le tableau est bien defini:

/*@ requires n >= 0 && \valid_range(t,0,n-1);

behavior success:

le tableau t est trie:

assumes \forall integer k1, k2;

0 <= k1 <= k2 <= n-1 ==> t[k1] <= t[k2];

v apparait dans t:

assumes \exists integer k; 0 <= k <= n-1 && t[k] == v;

ensures 0 <= \result <= n-1 && t[\result] == v;

behavior failure:

assumes // v does not appear anywhere in the array t

\forall integer k; 0 <= k <= n-1 ==> t[k] != v;

ensures \result == -1;

@*/

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 40 / 92

Specifications

Le tableau est bien defini:

/*@ requires n >= 0 && \valid_range(t,0,n-1);

behavior success:

le tableau t est trie:

assumes \forall integer k1, k2;

0 <= k1 <= k2 <= n-1 ==> t[k1] <= t[k2];

v apparait dans t:

assumes \exists integer k; 0 <= k <= n-1 && t[k] == v;

ensures 0 <= \result <= n-1 && t[\result] == v;

behavior failure:

assumes // v does not appear anywhere in the array t

\forall integer k; 0 <= k <= n-1 ==> t[k] != v;

ensures \result == -1;

@*/

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 40 / 92

Specifications

Le tableau est bien defini:

/*@ requires n >= 0 && \valid_range(t,0,n-1);

behavior success:

le tableau t est trie:

assumes \forall integer k1, k2;

0 <= k1 <= k2 <= n-1 ==> t[k1] <= t[k2];

v apparait dans t:

assumes \exists integer k; 0 <= k <= n-1 && t[k] == v;

ensures 0 <= \result <= n-1 && t[\result] == v;

behavior failure:

assumes // v does not appear anywhere in the array t

\forall integer k; 0 <= k <= n-1 ==> t[k] != v;

ensures \result == -1;

@*/

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 40 / 92

Specifications

Le tableau est bien defini:

/*@ requires n >= 0 && \valid_range(t,0,n-1);

behavior success:

le tableau t est trie:

assumes \forall integer k1, k2;

0 <= k1 <= k2 <= n-1 ==> t[k1] <= t[k2];

v apparait dans t:

assumes \exists integer k; 0 <= k <= n-1 && t[k] == v;

ensures 0 <= \result <= n-1 && t[\result] == v;

behavior failure:

assumes // v does not appear anywhere in the array t

\forall integer k; 0 <= k <= n-1 ==> t[k] != v;

ensures \result == -1;

@*/

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 40 / 92

Specifications

Le tableau est bien defini:

/*@ requires n >= 0 && \valid_range(t,0,n-1);

behavior success:

le tableau t est trie:

assumes \forall integer k1, k2;

0 <= k1 <= k2 <= n-1 ==> t[k1] <= t[k2];

v apparait dans t:

assumes \exists integer k; 0 <= k <= n-1 && t[k] == v;

ensures 0 <= \result <= n-1 && t[\result] == v;

behavior failure:

assumes // v does not appear anywhere in the array t

\forall integer k; 0 <= k <= n-1 ==> t[k] != v;

ensures \result == -1;

@*/Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 40 / 92

Recherche dichotomique

int low = 0;

int high = a.length - 1;

while (low <= high) {

int mid = low + (high-low) / 2;

int midVal = a[mid];

if (midVal < key)

low = mid + 1

else if (midVal > key)

high = mid - 1;

else

return mid; // key found

}

return -(low + 1); // key not found.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 41 / 92

De l’importance des specifications

Exemple du tri:

Pre-conditions: t est un tableau d’entiersPost-condition: le resultat est un tableau trie

Attention!Pre-conditions: t est un tableau d’entiers validePost-condition: le resultat est un tableau trie contenant les elements de t

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 42 / 92

Swap

/*@

requires \valid(p);

requires \valid(q);

assigns *p;

assigns *q;

ensures *p == \old(*q);

ensures *q == \old(*p);

*/

void swap(int* p, int* q)

int tmp = *p;

*p=*q;

*q=tmp;

return;

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 43 / 92

Swap

/*@

requires \valid(p);

requires \valid(q);

assigns *p;

assigns *q;

ensures *p == \old(*q);

ensures *q == \old(*p);

*/

void swap(int* p, int* q)

int tmp = *p;

*p=*q;

*q=tmp;

return;

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 43 / 92

Swap

/*@

requires \valid(p);

requires \valid(q);

assigns *p;

assigns *q;

ensures *p == \old(*q);

ensures *q == \old(*p);

*/

void swap(int* p, int* q)

int tmp = *p;

*p=*q;

*q=tmp;

return;

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 43 / 92

Swap

/*@

requires \valid(p);

requires \valid(q);

assigns *p;

assigns *q;

ensures *p == \old(*q);

ensures *q == \old(*p);

*/

void swap(int* p, int* q)

int tmp = *p;

*p=*q;

*q=tmp;

return;

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 43 / 92

Aparte: Proposition pedagogique

On peut faire ecrire les pre/post conditions aux etudiants en commentaire(pas forcement sous la forme d’une formule logique).Interet: expliciter la di↵erence entre les e↵ets de bord et le retour de la

fonction.

Exemple en C

/* effet de bord: incremente n.

resultat: renvoie le double de x. */

int toto(int x, int * n)

*n=*n+1;

return (2*x);

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 44 / 92

Contrats

Les contrats peuvent aussi etre exprimes sous forme de code:PyContracts, .Net CodeContracts, . . .

Exemple avec PyContracts@new_contract

def greater_than(value, thresh):

return value > thresh

@contract(x=’greater_than(3)’’)

def f(x):

....

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 45 / 92

Aparte: Notion d’e↵et de bord (side e↵ect)

DefinitionOn dit qu’une fonction realise un e↵et de bord quand son execution ne faitpas que retourner un resultat mais modifie l’etat global de l’ordinateur demaniere observable.

Exemples d’e↵ets de bord

modifier une variable statique ou globale

modifier un ou plusieurs de ses arguments

ecrire a l’ecran ou dans un fichier

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 46 / 92

Exemple

La fonction suivante modifie l’a�chage de l’ordinateur en a�chant“Bonjour” puis renvoie la valeur de son argument multipliee par 2.

En Cint mult2(int x) {

printf("Bonjour\n");

return(2*x);

}

En Python

def mult2(x):

print("Bonjour\n");

return(2*x)

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 47 / 92

Consequence

Cette fonction di↵ere de la fonction mathematiques x 7! 2x .En e↵et les programmes suivants ne se comportent pas pareil.

En Cint main() {

int x = 3;

int y = mult2(x)

+ mult2(x);

return(1);}

int main() {

int x = 3;

int y = 2*mult2(x);

return(1);}

En Python

def main():

x=3

y=mult2(x)+mult2(x)

return(1)

def main():

x=3

y=2*mult2(x)

return(1)

L’un ecrit Bonjour deux fois, l’autre qu’une seule fois.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 48 / 92

Approche par extraction ou ra�nement

On (re-)ecrit le code avec l’intention de le prouver directement dans unlangage fait pour faire des preuves. Avantage: on evite les mauvaisproprietes de certains langages: par exemple les pointeurs.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 49 / 92

Verification et validation :

environ 30% du developpement d’un logiciel standard

plus de 50% du developpement d’un logiciel critique

Validation ?Les tests permettent de detecter des erreurs, pas de verifier qu’unprogramme est correct.

“Testing can only reveal the presence of errors but never theirabsence.” - E. W. Dijkstra

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 50 / 92

Table des matieres1 Le probleme

2 TypageTypage statique vs dynamiqueHoare’s “billion-dollard mistake”

3 TestGeneralitesTest unitaires

4 Preuve de programmesApproche preuve du programme originalApproche par extraction

5 Les assistants de preuveQuelques succesQui verifie le verificateur ?Automatisation

6 Curry-Howard

7 Un exemple en geometrie

8 Conclusion

Qu’est-ce qu’une preuve ?

1 un argument convainquant

2 une suite de deductions a partir des axiomes

3 un algorithme (correspondance de Curry-Howard)

Remarque

On peut voir une preuve informelle comme un argument pour convaincreun mathematicien de l’existence d’une preuve formelle.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 52 / 92

Qu’est-ce qu’une preuve ?

1 un argument convainquant

2 une suite de deductions a partir des axiomes

3 un algorithme (correspondance de Curry-Howard)

Remarque

On peut voir une preuve informelle comme un argument pour convaincreun mathematicien de l’existence d’une preuve formelle.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 52 / 92

Qu’est-ce qu’une preuve ?

1 un argument convainquant

2 une suite de deductions a partir des axiomes

3 un algorithme (correspondance de Curry-Howard)

Remarque

On peut voir une preuve informelle comme un argument pour convaincreun mathematicien de l’existence d’une preuve formelle.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 52 / 92

Qu’est-ce qu’une preuve ?

1 un argument convainquant

2 une suite de deductions a partir des axiomes

3 un algorithme (correspondance de Curry-Howard)

Remarque

On peut voir une preuve informelle comme un argument pour convaincreun mathematicien de l’existence d’une preuve formelle.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 52 / 92

Qu’est-ce qu’une preuve ?

1 un argument convainquant

2 une suite de deductions a partir des axiomes

3 un algorithme (correspondance de Curry-Howard)

Remarque

On peut voir une preuve informelle comme un argument pour convaincreun mathematicien de l’existence d’une preuve formelle.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 52 / 92

Oui mais...

Il peut etre di�cile de se convaincre qu’une preuve est correcte :

1 presence de calculs non verifiables a la main

2 preuves tres longues, tres compliquees

3 trop de details techniques, trop de cas pour les traiter a la main sansfaire d’erreurs

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 53 / 92

Oui mais...

Il peut etre di�cile de se convaincre qu’une preuve est correcte :

1 presence de calculs non verifiables a la main

2 preuves tres longues, tres compliquees

3 trop de details techniques, trop de cas pour les traiter a la main sansfaire d’erreurs

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 53 / 92

Oui mais...

Il peut etre di�cile de se convaincre qu’une preuve est correcte :

1 presence de calculs non verifiables a la main

2 preuves tres longues, tres compliquees

3 trop de details techniques, trop de cas pour les traiter a la main sansfaire d’erreurs

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 53 / 92

L’histoire des preuvesUne quete de la rigueur

1 Clarifier les hypotheses

2 Clarifier ce qu’est une preuve

3 Etre si precis que l’on a plus besoin de comprendre la preuve pour laverifier

4 Automatiser des preuves

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 54 / 92

L’histoire des preuvesUne quete de la rigueur

1 Clarifier les hypotheses

2 Clarifier ce qu’est une preuve

3 Etre si precis que l’on a plus besoin de comprendre la preuve pour laverifier

4 Automatiser des preuves

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 54 / 92

L’histoire des preuvesUne quete de la rigueur

1 Clarifier les hypotheses

2 Clarifier ce qu’est une preuve

3 Etre si precis que l’on a plus besoin de comprendre la preuve pour laverifier

4 Automatiser des preuves

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 54 / 92

L’histoire des preuvesUne quete de la rigueur

1 Clarifier les hypotheses

2 Clarifier ce qu’est une preuve

3 Etre si precis que l’on a plus besoin de comprendre la preuve pour laverifier

4 Automatiser des preuves

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 54 / 92

Heureusement !Par definition verifier qu’une preuve est correcte est un probleme decidable.

On peut donc construire des assistants de preuve!

Exemples

Coq

Isabelle

PVS

HOL-Light

. . .

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 55 / 92

Heureusement !Par definition verifier qu’une preuve est correcte est un probleme decidable.

On peut donc construire des assistants de preuve!

Exemples

Coq

Isabelle

PVS

HOL-Light

. . .

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 55 / 92

Qu’est-ce que Coq ?

un assistant de preuve

developpe et distribue librement par Inria

Il permet de :

definir des notions mathematiques et/ou des programmes

demontrer mecaniquement des theoremes mathematiques mettant enjeu ces definitions

Qu’est-ce que Coq n’est pas ?

Un prouveur automatique

Un outil qui facilite l’obtention des preuves

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 56 / 92

Qu’est-ce que Coq ?

un assistant de preuve

developpe et distribue librement par Inria

Il permet de :

definir des notions mathematiques et/ou des programmes

demontrer mecaniquement des theoremes mathematiques mettant enjeu ces definitions

Qu’est-ce que Coq n’est pas ?

Un prouveur automatique

Un outil qui facilite l’obtention des preuves

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 56 / 92

Processus de preuve

Les deux etapes du developpement d’une demonstration dans Coq sont lessuivantes :

d’abord la construction interactive d’une demonstration parl’utilisateur ;

ensuite la verification automatique de la correction dedemonstration par le systeme.

L’utilisateur prouve, puis le systeme verifie que la preuve est bien

correcte.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 57 / 92

Exemples d’enonces mathematiques

”Si les portes sont ouvertes c’est que la rame est en face d’un quai”.

nX

0

i =n(n + 1)

2

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 58 / 92

Demo

On veut montrer que:nX

i=0

i =n(n + 1)

2

On va montrer que:

2 ⇤nX

i=0

i = n(n + 1)

En Coq:

Lemma sun_n : forall n:nat, 2 * (sum_int n) = n*(n+1).

Oui mais comment est definie l’operationP

?

0X

i=0

i = 0

nX

i=0

i = n +n�1X

i=0

i

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 59 / 92

Demo

On veut montrer que:nX

i=0

i =n(n + 1)

2

On va montrer que:

2 ⇤nX

i=0

i = n(n + 1)

En Coq:

Lemma sun_n : forall n:nat, 2 * (sum_int n) = n*(n+1).

Oui mais comment est definie l’operationP

?

0X

i=0

i = 0

nX

i=0

i = n +n�1X

i=0

i

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 59 / 92

Demo

On veut montrer que:nX

i=0

i =n(n + 1)

2

On va montrer que:

2 ⇤nX

i=0

i = n(n + 1)

En Coq:

Lemma sun_n : forall n:nat, 2 * (sum_int n) = n*(n+1).

Oui mais comment est definie l’operationP

?

0X

i=0

i = 0

nX

i=0

i = n +n�1X

i=0

i

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 59 / 92

Demo

On veut montrer que:nX

i=0

i =n(n + 1)

2

On va montrer que:

2 ⇤nX

i=0

i = n(n + 1)

En Coq:

Lemma sun_n : forall n:nat, 2 * (sum_int n) = n*(n+1).

Oui mais comment est definie l’operationP

?

0X

i=0

i = 0

nX

i=0

i = n +n�1X

i=0

i

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 59 / 92

Demo

On veut montrer que:nX

i=0

i =n(n + 1)

2

On va montrer que:

2 ⇤nX

i=0

i = n(n + 1)

En Coq:

Lemma sun_n : forall n:nat, 2 * (sum_int n) = n*(n+1).

Oui mais comment est definie l’operationP

?

0X

i=0

i = 0

nX

i=0

i = n +n�1X

i=0

i

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 59 / 92

Le probleme de la verification d’une preuvePresence de calculs

Theoreme des 4 couleursQuatre couleurs su�sent pour colorier une carte geographique plane sansque deux pays ayant une frontiere en commun ne soient de la memecouleur.

1879 ”Preuve” fausse par Kempe

1890 Heaywood trouve l’erreur

1976 Appel and Hake (1478 configurations, 1200 heures de calcul)

2004 Formalisation en Coq par Gonthier et Werner

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 60 / 92

Conjecture de Kepler/Theoreme de Hales

Pour un empilement de spheres egales, ladensite maximale est atteinte pour unempilement cubique a faces centrees.

Photo par Robert

Cudmore

1998 Preuve par Thomas HalesRobert MacPherson, editeur, ecrit que:“The news from the referees is bad, from my perspective. They have not been

able to certify the correctness of the proof, and will not be able to certify it in

the future, because they have run out of energy to devote to the problem.

This is not what I had hoped for. The referees put a level of energy into this

that is, in my experience, unprecedented.”

2004 - 2014 Projet Flyspeck: formalisation du theoreme en cours enHOL-light avec des contributions en Coq et Isabelle

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 61 / 92

Le probleme de la verification d’une preuveTrop de details techniques

Un compilateur

CompCert un compilateur C prouve formellement (Xavier Leroy).Genere de l’assembleur PowerPC et ARM a partir de code C.Preuve formelle de la correction: le code assembleur se comporte de lameme maniere que le code source.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 62 / 92

Le probleme de la verification d’une preuveTrop de details techniques

Systeme de pilotage d’une ligne de metro

Methode B

Paris (ligne 14, 1998), Paris(ligne 1, 2005), Lyon (ligne D),. . .

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 63 / 92

Le probleme de la verification d’une preuveTrop de details techniques

Un systeme d’exploitation

sel4 : Micro kernel prouve en Isabelle/HOL.Preuve: 165000 lignes, 11 annees/homme.Code: 15000 lignes, 2.5 annees/homme.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 64 / 92

Le probleme de la verification d’une preuve ILa taille de la preuve

Theoreme de Feit-Thompson

Theorem Feit_Thompson (gT:finGroupType) (G:{group gT}):

odd ##|G| -> solvable G.

Preuve en Coq par Georges Gonthier et son equipe (septembre 2012)a:170 000 lignes, 15 000 definitions, 4 200 theoremes

a

http://ssr2.msr-inria.inria.fr/

~

jenkins/current/progress.html

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 65 / 92

Autres exemples

http://www.cs.ru.nl/~freek/100/index.html

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 66 / 92

Le probleme de la verification d’une preuveTrop de details techniques

Un systeme de gestion de cartes a puces

Gemalto: preuve formelle avec Coq.Certification d’un systeme JavaCardau niveau EAL7.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 67 / 92

Qui verifie le verificateur ?

Il faut faire confiance a:la theorie sous jacente a l’assistant de preuve et

que l’implantation correspond bien a la theorie et

au compilateur et

au microprocesseur et

a vos definitions et enonces et

a vos axiomes.

Critere de de Bruijn

Les preuves sont certifiee par un noyau.Isabelle (tres petit)HOL (tres petit)Coq (relativement petit)

En revanche, ni Mizar, ni PVS n’ont une notion de noyau.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 68 / 92

Qui verifie le verificateur ?

Il faut faire confiance a:la theorie sous jacente a l’assistant de preuve et

que l’implantation correspond bien a la theorie et

au compilateur et

au microprocesseur et

a vos definitions et enonces et

a vos axiomes.

Critere de de Bruijn

Les preuves sont certifiee par un noyau.Isabelle (tres petit)HOL (tres petit)Coq (relativement petit)

En revanche, ni Mizar, ni PVS n’ont une notion de noyau.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 68 / 92

Qui verifie le verificateur ?

Il faut faire confiance a:la theorie sous jacente a l’assistant de preuve et

que l’implantation correspond bien a la theorie et

au compilateur et

au microprocesseur et

a vos definitions et enonces et

a vos axiomes.

Critere de de Bruijn

Les preuves sont certifiee par un noyau.Isabelle (tres petit)HOL (tres petit)Coq (relativement petit)

En revanche, ni Mizar, ni PVS n’ont une notion de noyau.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 68 / 92

Qui verifie le verificateur ?

Il faut faire confiance a:la theorie sous jacente a l’assistant de preuve et

que l’implantation correspond bien a la theorie et

au compilateur et

au microprocesseur et

a vos definitions et enonces et

a vos axiomes.

Critere de de Bruijn

Les preuves sont certifiee par un noyau.Isabelle (tres petit)HOL (tres petit)Coq (relativement petit)

En revanche, ni Mizar, ni PVS n’ont une notion de noyau.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 68 / 92

Qui verifie le verificateur ?

Il faut faire confiance a:la theorie sous jacente a l’assistant de preuve et

que l’implantation correspond bien a la theorie et

au compilateur et

au microprocesseur et

a vos definitions et enonces et

a vos axiomes.

Critere de de Bruijn

Les preuves sont certifiee par un noyau.Isabelle (tres petit)HOL (tres petit)Coq (relativement petit)

En revanche, ni Mizar, ni PVS n’ont une notion de noyau.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 68 / 92

Qui verifie le verificateur ?

Il faut faire confiance a:la theorie sous jacente a l’assistant de preuve et

que l’implantation correspond bien a la theorie et

au compilateur et

au microprocesseur et

a vos definitions et enonces et

a vos axiomes.

Critere de de Bruijn

Les preuves sont certifiee par un noyau.Isabelle (tres petit)HOL (tres petit)Coq (relativement petit)

En revanche, ni Mizar, ni PVS n’ont une notion de noyau.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 68 / 92

Qui verifie le verificateur ?

Il faut faire confiance a:la theorie sous jacente a l’assistant de preuve et

que l’implantation correspond bien a la theorie et

au compilateur et

au microprocesseur et

a vos definitions et enonces et

a vos axiomes.

Critere de de Bruijn

Les preuves sont certifiee par un noyau.Isabelle (tres petit)HOL (tres petit)Coq (relativement petit)

En revanche, ni Mizar, ni PVS n’ont une notion de noyau.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 68 / 92

Qui verifie le verificateur ?

Il faut faire confiance a:la theorie sous jacente a l’assistant de preuve et

que l’implantation correspond bien a la theorie et

au compilateur et

au microprocesseur et

a vos definitions et enonces et

a vos axiomes.

Critere de de Bruijn

Les preuves sont certifiee par un noyau.Isabelle (tres petit)HOL (tres petit)Coq (relativement petit)

En revanche, ni Mizar, ni PVS n’ont une notion de noyau.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 68 / 92

Et l’automatisation ?

Une approche sceptique: on ne fait pas confiances aux demonstrateursautomatiques.Deux solutions:

1 Prouver le prouveur.

2 Verifier le resultat du prouveur: un certificat.

Exemples

Egalite entre deux expressions prises dans un anneau ou dans uncorps.

Tautologies.

Inegalites lineaires.

Theoremes en geometrie.

. . .

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 69 / 92

Table des matieres1 Le probleme

2 TypageTypage statique vs dynamiqueHoare’s “billion-dollard mistake”

3 TestGeneralitesTest unitaires

4 Preuve de programmesApproche preuve du programme originalApproche par extraction

5 Les assistants de preuveQuelques succesQui verifie le verificateur ?Automatisation

6 Curry-Howard

7 Un exemple en geometrie

8 Conclusion

Correspondance de Curry-Howard I

f : string ! int a : string

f (a) :

int

Regle de typage de l’application:

f : A ! B a : A

f (a) : B

Modus ponens:A ) B A

B

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 71 / 92

Correspondance de Curry-Howard I

f : string ! int a : string

f (a) : int

Regle de typage de l’application:

f : A ! B a : A

f (a) : B

Modus ponens:A ) B A

B

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 71 / 92

Correspondance de Curry-Howard I

f : string ! int a : string

f (a) : int

Regle de typage de l’application:

f : A ! B a : A

f (a) : B

Modus ponens:A ) B A

B

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 71 / 92

Correspondance de Curry-Howard I

f : string ! int a : string

f (a) : int

Regle de typage de l’application:

f : A ! B a : A

f (a) : B

Modus ponens:A ) B A

B

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 71 / 92

Correspondance de Curry-Howard I

f : string ! int a : string

f (a) : int

Regle de typage de l’application:

f :

A ! B

a :

A

f (a) :

B

Modus ponens:A ) B A

B

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 71 / 92

Correspondance de Curry-Howard I

logique programmation

�,A ` B� ` A ) B

�, x : A ` t : B� ` (fun x : A 7! t) : A ! B

� ` A ) B � ` A� ` B

� ` f : A ! B � ` a : A� ` f (a) : B

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 72 / 92

Correspondance de Curry-Howard I

logique programmation

�,A ` B� ` A ) B

�,

x :

A `

t :

B� `

(fun x : A 7! t) :

A ! B

� ` A ) B � ` A� ` B

� `

f :

A ! B � `

a :

A� `

f (a) :

B

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 72 / 92

Correspondance de Curry-Howard I

logique programmation

�,A ` B� ` A ! B

�,

x :

A `

t :

B� `

(fun x : A 7! t) :

A ! B

� ` A ! B � ` A� ` B

� `

f :

A ! B � `

a :

A� `

f (a) :

B

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 72 / 92

Correspondance de Curry-Howard II

� ` A � ` B� ` A ^ B

� ` a : A � ` b : B� ` (a, b) :

A⇥ B

� ` A ^ B� ` A

� ` t : A⇥ B� `

fst t :

A

� ` A ^ B� ` B

� ` t : A⇥ B� `

snd t :

B

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 73 / 92

Correspondance de Curry-Howard II

� ` A � ` B� ` A ^ B

� ` a : A � ` b : B� ` (a, b) : A⇥ B

� ` A ^ B� ` A

� ` t : A⇥ B� `

fst t :

A

� ` A ^ B� ` B

� ` t : A⇥ B� `

snd t :

B

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 73 / 92

Correspondance de Curry-Howard II

� ` A � ` B� ` A ^ B

� ` a : A � ` b : B� ` (a, b) : A⇥ B

� ` A ^ B� ` A

� ` t : A⇥ B� `

fst t :

A

� ` A ^ B� ` B

� ` t : A⇥ B� `

snd t :

B

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 73 / 92

Correspondance de Curry-Howard II

� ` A � ` B� ` A ^ B

� ` a : A � ` b : B� ` (a, b) : A⇥ B

� ` A ^ B� ` A

� ` t : A⇥ B� ` fst t : A

� ` A ^ B� ` B

� ` t : A⇥ B� ` snd t : B

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 73 / 92

Correspondance de Curry-Howard III

� ` A� ` A _ B

� ` a : A� ` inl a : A+ B

� ` B� ` A _ B

� ` b : B� ` inr b : A+ B

� ` A _ B �,A ` C �,B ` C

� ` C

� ` m : A _ B �, x : A ` t : C �, x : B ` u : C

� ` case m of inl(a) => t | inr(a) => u : C

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 74 / 92

Regles de simplification

fst(A,B) = Asnd(A,B) = B

case (inl m) of inl(a) => t|inr(a) => u = t[x := m]case (inr m) of inl(a) => t|inr(a) => u = u[x := m]

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 75 / 92

Correspondance de Curry-Howard

Logique �-calcul/programmation

formule typepreuve terme/programme

verification d’une demonstration verification de typenormalisation des preuves �-reduction/calcul

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 76 / 92

Semantique de Heyting-Kolmogorov

La semantique de Heyting-Kolmogorov consiste a donner uneinterpretation fonctionnelle des demonstrations.

Une preuve de A ! B est une fonction qui, a partir d’une preuve deA donne une preuve de B .

Une preuve de A ^ B est une paire composee d’une preuve de A etd’une preuve de B .

Une preuve de A _ B est une paire (i , p) avec (i = 0 et p une preuvede A) ou (i = 1 et p une preuve de B).

Une preuve de 8x .A est une fonction qui, pour chaque objet tconstruit un objet de type A[x := t].

Cette interpretation consiste a calculer avec des preuves. Cela paraıt tresproche de la programmation fonctionnelle et du �-calcul.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 77 / 92

Retour sur la correspondance de Curry-Howard a travers lacurryfication

Definition curry A B C (f:(A * B) -> C)

(x:A) (y:B) := f(x,y).

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 78 / 92

Lemma curry_prop: forall A B C : Type,

(A * B -> C) -> A -> B -> C.

Proof.

intros A B C f x y.

apply f.

split.

apply x.

apply y.

Defined.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 79 / 92

Print curry_prop.

On obtient:

curry_prop =

fun (A B C : Type) (f : A * B -> C)

(x : A) (y : B) => f (x, y)

: forall A B C : Type,

(A * B -> C) -> A -> B -> C

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 80 / 92

Table des matieres1 Le probleme

2 TypageTypage statique vs dynamiqueHoare’s “billion-dollard mistake”

3 TestGeneralitesTest unitaires

4 Preuve de programmesApproche preuve du programme originalApproche par extraction

5 Les assistants de preuveQuelques succesQui verifie le verificateur ?Automatisation

6 Curry-Howard

7 Un exemple en geometrie

8 Conclusion

Le geometrie est centrale dans l’histoire des preuves

Euclid (�325-�265) The Elements.La methode axiomatique

Hilbert (1862-1943) Die Grundlagen derGeometrie.Les mathematiques formelles

Tarski (1902-1983) MetamathematischeMethoden in der Geometrie.Automatisation, axiomatisation

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 82 / 92

Le geometrie est centrale dans l’histoire des preuves

Euclid (�325-�265) The Elements.La methode axiomatique

Hilbert (1862-1943) Die Grundlagen derGeometrie.Les mathematiques formelles

Tarski (1902-1983) MetamathematischeMethoden in der Geometrie.Automatisation, axiomatisation

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 82 / 92

Le geometrie est centrale dans l’histoire des preuves

Euclid (�325-�265) The Elements.La methode axiomatique

Hilbert (1862-1943) Die Grundlagen derGeometrie.Les mathematiques formelles

Tarski (1902-1983) MetamathematischeMethoden in der Geometrie.Automatisation, axiomatisation

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 82 / 92

Mais a aussi mene a une longue succession de . . .

. . . preuves fausses !

En 1763, dans sa these Klugel une liste de 30 preuves fausse du postulatdes paralleles” [?].

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 83 / 92

Notre projet

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 84 / 92

Exemple

TheoremEtant donne un triangle ABC, soit P le milieu de BC et Q le milieu de ACles droites AB et PQ sont paralleles.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 85 / 92

Idee de la “preuve”

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 86 / 92

Idee de la “preuve”

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 86 / 92

Idee de la “preuve”

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 86 / 92

Idee de la “preuve”

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 86 / 92

Idee de la “preuve”

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 86 / 92

Idee de la “preuve”

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 86 / 92

Idee de la “preuve”

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 86 / 92

Idee de la “preuve”

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 86 / 92

Idee de la “preuve”

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 86 / 92

Idee de la “preuve”

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 86 / 92

Idee de la “preuve”

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 86 / 92

Un probleme dans la preuve ”papier”.

^

# .

_

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 87 / 92

Un probleme dans la preuve ”papier”.

^

# .

_

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 87 / 92

Un probleme dans la preuve ”papier”.

^

. #

_

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 87 / 92

Formalisation Coq

In a given triangle ABC where P is the midpoint of

ˆBC and Q the midpoint of

ˆAC we have

that AB and PQ are parallel and PQ =

AB2 .

X is the inversion of P with respect to Q so Q is the midpoint of the segment

ˆPX.

We also have that Q is the midpoint of

ˆAC.

The quadrilateral APCX has then its diagonals which meet in their midpoint. The quadri-

lateral APCX is therefore a parallelogram.

A parallelogram has its opposite sides which are parallel and of the same length.

So AX and CP are parallel and AX = CP .

P is the midpoint of

ˆBC so BP = PC.

As we proved that AX = CP we have that BP = AX.

Moreover we showed that AX and CP are parallels.

As B, P and C are collinear we can also say that AX and BP are parallel.

The quadrilateral ABPX has then two opposite sides which are parallel and of the same

length and is therefore a parallelogram.

Since ABPX is a parallelogram its opposite sides are parallel and of the same length.

Particularly AB and PX are parallel and AB = PX.

As Q is the middle of

ˆPX we know that PQ =

PX2 =

AB2 .

Finally as P , Q and X are collinear we can also say that PQ and AB are parallel.

Lemma

triangle_mid_par_strict_cong_simp : forall A B C P Q,

~ Col A B C -> is_midpoint P B C -> is_midpoint Q A C ->

Par_strict A B Q P.

Proof with assert_all.

intros.

Name X the symmetric of P wrt Q...

assert (~ Col A P C) by (intro; search_contradiction)...

assert (Parallelogram_strict A P C X) by (apply mid_plgs with Q;finish)...

assert_paras.

assert_pars.

assert (Cong A X B P) by eCong.

assert (Par A X B P) by (apply par_col2_par with P C; finish).

assert (HElim : Parallelogram A X B P \/ Parallelogram A X P B)

by (apply par_cong_plg_2; assumption).

induction HElim.

- (* Impossible case. *)

Name M the intersection of the diagonals (A B) and (X P) of the parallelogram H25.

treat_equalities.

search_contradiction.

- assert_paras.

assert_pars.

assert (Par P Q A B) by (apply par_col_par_2 with X; finish).

apply par_not_col_strict with X;finish.

intro.

assert_cols.

apply H. ColR.

Qed.

Pas (encore) utilisable en classe.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 88 / 92

Table des matieres1 Le probleme

2 TypageTypage statique vs dynamiqueHoare’s “billion-dollard mistake”

3 TestGeneralitesTest unitaires

4 Preuve de programmesApproche preuve du programme originalApproche par extraction

5 Les assistants de preuveQuelques succesQui verifie le verificateur ?Automatisation

6 Curry-Howard

7 Un exemple en geometrie

8 Conclusion

Comparaison des methodes de verification

Tests: Mise en oeuvre relativement facile.Necessaire: on trouve des erreurs dans le systemecomplet: specification et implantation.

“Beware of bugs in the above code; I have onlyproved it correct, not tried it.” Donald Knuth

Pas su�sant: exhaustivite impossible

Preuves: Exhaustif.Di�cile a mettre en œuvre, necessite du personnelforme.

Analyse statique par interpretation abstraite:

Exhaustif pour certaines classes de problemes (safety).N’est pas applicable a tous les programmes.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 90 / 92

Conclusion

Il existe des logiciels pour verifier les preuves.On peut les utiliser pour des preuves de programmes ou de theoremesmathematiques.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 91 / 92

Merci de votre attention.

Julien Narboux (Universite de Strasbourg) Du bug a la preuve 2013 92 / 92