Preuve ou raisonnement ?
Le 16 mai 2003, l’Université d’Anvers a décerné un titre de docteur honoris causa à Donald E. Knuth. Comme c’est souvent l’usage, le récipiendaire donne une conférence sur un sujet de son choix. La veille de la cérémonie, Donald Knuth fit un exposé sur Le plaisir de l’illustration technique (« The Joy of Technical Illustration ») qui attira un nombre impressionnant d’auditeurs rassemblés dans l’un des plus vastes amphithéâtres de l’université.
Knuth présenta rapidement le langage METAPOST qui permet de décrire, sous la forme d’un programme, des illustrations telles qu’elles peuvent apparaître dans des ouvrages techniques : essentiellement des schémas combinant des « boîtes » et des arcs entre celles-ci. (Nous utilisons le terme « boîte » parce qu’il ne s’agit pas toujours de rectangles, mais de cercles ou d’ellipses ou d’autres figures plus ou moins régulières contenant une information, souvent textuelle.) Les lecteurs qui ont lu les ouvrages de Knuth (Knuth, 1997 ; 1998) reconnaîtront le genre de schémas (ordinogrammes, arbres, graphes) qui les illustrent. METAPOST permet de décrire ces schémas d’une manière topologique ; par exemple, la dimension et la disposition des « boîtes » s’adaptent à l’espace requis pour représenter les légendes insérées dans les « boîtes » ou associées aux arcs ; une propriété très intéressante pour adapter un schéma lors de la traduction d’un ouvrage. Une multitude d’exemples extraits de la nouvelle édition de The Art of Computer Programming (Knuth, 1997) illustraient l’exposé.
Tous les ouvrages écrits par Knuth m’ont toujours fortement impressionné par la qualité de leur contenu et la recherche d’une perfection dans la rédaction.
Curieusement, aucun des exposés de Knuth auxquels j’ai assisté ne m’ont laissé la même impression. Cette déception provient du souhait qu’un exposé soit centré sur la transmission d’une forme de « message » qui puisse servir à une réflexion personnelle ultérieure. Les exposés de Knuth rencontrent ce souhait, mais jamais de manière explicite. L’exposé est peu structuré, trop abondamment illustré par une succession rapide de transparents (débités sur deux rétroprojecteurs, dans le cas présent) ; et brusquement, sans préparation de l’attention de l’auditoire, une remarque importante est glissée entre deux transparents anodins. L’efficacité de l’exposé est réduite : la majorité des auditeurs ne perçoivent probablement l’importance de la phrase que s’ils sont déjà familiarisés avec le domaine.
Lors de cet exposé, l’auditoire était en grande partie composé d’étudiants en informatique provenant de diverses institutions, rabattus vers l’amphithéâtre par leurs professeurs respectifs. Vu mon expérience d’exposés antérieurs, je m’étais bien gardé de faire trop de publicité auprès de mes étudiants. Je ne le regrettai pas car, à
l’issue de l’exposé, il était clair que les jeunes auditeurs étaient nombreux à se demander d’où pouvait bien provenir l’enthousiasme de leurs professeurs pour le conférencier.
Dans cet exposé, j’ai relevé deux remarques qui auraient mérité d’être suffisamment amplifiées pour attirer l’attention des jeunes étudiants. La première concerne les programmes d’application ; la deuxième, l’étude des démonstrations des théorèmes dans les cours de mathématiques.
Dans une première remarque, Knuth rappela aux auditeurs que la plupart des schémas dans les trois tomes de The Art of Computer Programming sont des arbres ou des graphes. Ultérieurement, il signala que, pratiquement pour chaque arbre représenté, la structure du programme METAPOST est propre à cet arbre. Il en résulte que proposer une bibliothèque de programmes de dessin d’arbres sur la base de l’expérience acquise par la rédaction des trois tomes conduirait à une collection de nombreuses routines. Le manuel de l’utilisateur serait excessivement volumineux
; en effet, il est très difficile de décrire l’effet d’une routine METAPOST, car le résultat est un objet graphique à deux dimensions dont les caractéristiques paramétrables sont complexes. Plus tard dans l’exposé, il expliqua que, METAPOST étant un langage de programmation, sa description est très concise, et que, après une période d’apprentissage relativement courte, un programmeur qui a la pratique de l’algorithmique parvient rapidement à composer le programme générant le schéma dont il possède une représentation mentale ou un simple croquis.
Dans un contexte où la recherche de « packages » sur le réseau est une des méthodes de résolution prônée par certains, ce point méritait de plus amples développements, et non d’être écartelé en trois remarques séparées par diverses digressions dans l’exposé.
Soudainement, en exposant une propriété des arbres qui lui était vraisemblablement rappelée par un des exemples qu’il projetait, Knuth déclara qu’il avait constaté « n’avoir pratiquement jamais utilisé un théorème vu dans un cours de mathématiques. » La suite du propos précisant le sens de sa remarque : Pratiquement il a toujours été amené à devoir prouver un résultat voisin ou dérivé d’un théorème donné, l’énoncé original n’étant pas directement applicable au cas étudié. Finalement l’intervention se termine par une conclusion des plus importantes : C’est certainement une erreur d’enseigner ou d’étudier une démonstration en pensant que ce qui compte c’est le théorème à prouver ; c’est la méthode de démonstration qui importe. Et puis, on passe à un autre transparent...
Probablement que d’autres remarques glissées entre deux transparents ont attiré l’attention d’autres auditeurs en fonction de leurs centres de préoccupation. La méthode d’exposé de Knuth est sans doute profitable dans ce sens ; mais elle me semble peu adéquate pour capter l’attention quand l’auditoire est essentiellement composé d’étudiants.
La remarque de Knuth sur les démonstrations nous ramène à un paradoxe des cours de mathématiques : les démonstrations forment le cœur du domaine, mais la manière de développer une démonstration est rarement enseignée. Les étudiants en gardent la perception que les résultats démontrés forment l’essentiel, et que leur utilisation sera primordiale dans les applications. Souvent, les exercices sont organisés pour renforcer cette vision : la connaissance des thèses des théorèmes démontrés est le point de départ de la résolution. Si on accepte la pertinence de la remarque de Knuth, cette conception classique d’un cours de mathématique s’écroule : les théorèmes démontrés ne servent à rien ! On songe à la phrase d’Alain : Les cours magistraux sont temps perdu. Les notes prises ne servent jamais. ... Il faut essayer, faire, refaire, jusqu’à ce que le métier entre, comme on dit. ... Et puis encore, tout effacé, il faudra refaire, réciter, varier en récitant, chercher des exemples, changer les exemples. On dira que c’est long ; mais à quoi sert un travail qui ne laisse rien. (Alain, 1956, p. 1044-1045)
En parcourant les trois tomes de The Art of Computer Programming, on comprend la remarque de Knuth : quand une nouvelle structure de données est introduite, quand un nouvel algorithme est conçu, il importe de trouver certaines propriétés qui permettront de comparer la structure de données ou l’algorithme à d’autres afin d’en justifier l’intérêt ; chaque propriété fait l’objet d’une démonstration ; mais c’est très rare que cette démonstration soit une simple récupération d’un théorème antérieur, et même dans ce cas, la récupération doit être préparée par un raisonnement original. Par exemple, voir la démonstration de la hauteur d’un arbre équilibré contenant N nœuds, (Knuth, 1998, p. 460.).
Mais le problème de la perception des démonstrations est beaucoup plus vaste : non seulement l’idée que seuls les résultats démontrés ont une importance pratique, mais aussi celle que la conception d’une démonstration n’est pas du ressort du praticien engagé dans le développement d’une solution sont largement répandues.
Les démonstrations restent l’apanage de quelques spécialistes.
Même Knuth semble suivre cette vision du rôle de la démonstration. Dans les premières pages du premier tome (Knuth, 1997, p.10-18), il expose l’utilisation d’assertions et de l’induction mathématique pour prouver l’exactitude des algorithmes. Mais la méthode proposée n’est jamais appliquée par la suite. Pourtant, il connaissait la méthode dès sa conception par Robert Floyd, comme il le raconte dans (Knuth, 2003).
Bob me montra les travaux qu’il avait faits concernant des techniques mathématiques pour vérifier qu’un programme est correct - une idée complètement inconnue à cette époque [1962]. La méthode suivie pour construire un programme était tout le contraire : on écrivait du code et on le testait, ensuite trouver les bogues et écrire des corrections, ensuite trouver plus de bogues et écrire plus de corrections, et ainsi de suite jusqu’à ne plus être capable de trouver de nouvelles erreurs, mais en vivant dans la peur qu’un nouveau cas apparaisse le lendemain provoquant un nouveau type d’erreur. Nous n’avions jamais réalisé qu’il pouvait
exister une façon de construire une preuve rigoureuse de la validité d’un programme ; en tout cas, je suis certain que de telles pensées ne m’ont jamais traversé l’esprit quand j’écrivais des programmes, et pourtant lorsque j’étais dans une salle de cours, je ne faisais que des démonstrations.
Déjà dans la première édition de (Knuth, 1997), en 1968, la méthode de Floyd est exposée. La méthode de Floyd est de spécifier entre deux commandes d’un programme une assertion qui exprime les relations essentielles vérifiées par les variables en ce point de l’exécution. Plus exactement, Floyd considère un algorithme représenté par un ordinogramme (flowchart) ; les assertions sont associées aux branches de l’ordinogramme. Mais, probablement que, même pour Floyd, la démonstration de la validité d’un algorithme n’était vue que comme une activité exceptionnelle qui ne serait pas du ressort du praticien. En effet, au congrès IFIP en 1971, Floyd présente comme objectif de recherche la mise au point d’un système interactif qui aide le programmeur à développer une preuve de programme. (Floyd, 1971). Dans ce système, Floyd imagine que seules des assertions cruciales sont fournies par le programmeur ; le système complète l’étiquetage des branches de l’ordinogramme en utilisant les assertions données et les commandes de l’algorithme.
Il faut accepter les faits : quarante ans après les premiers travaux sur la preuve des programmes, la technique est peu répandue, elle reste d’un usage exceptionnel ou bien lié à un système d’aide au développement. Les travaux sur le développement simultané de la preuve et du programme (au lieu d’une preuve a posteriori établie sur un algorithme donné comme le propose Floyd), exposés par Dijkstra, voir (Dijkstra, 1976), ont conduit à une vaste littérature d’ouvrages consacrés à la mise en œuvre de la méthode (par exemples, (Cohen, 1990 ; Dijkstra, 1988 ; Gries 1981, 1993 ; Kaldewaij, 1990 ; Van den Snepscheut, 1993), et plus récemment (Backhouse, 2003)). Toutefois la lecture de ces textes ne peut entraîner une adhésion sans réserve à la méthode : les multiples formules manipulées pendant le développement obscurcissent l’essentiel de la solution. Parfois, l’exposé d’un algorithme classique correspond à une « réécriture » qui fait complètement disparaître l’idée de base de l’algorithme. Par exemple, l’algorithme de tri par tas est pour nous intrinsèquement lié à la notion de structure de tas ; dans une description
« constructive », le tas est introduit par la définition formelle d’un ordre partiel dont la liaison avec la représentation habituelle d’un tas est loin d’être immédiate (pour les détails, voir (Kaldewaij, 1990, p. 187-193) ; la représentation classique du tas n’est même pas donnée (la manipulation des expressions formelles ne permettant pas d’inclure des figures). Ces « réécritures » donnent un caractère artificiel aux algorithmes exposés : on peut suivre étape par étape la justification formelle, mais on peut difficilement en retirer une vision d’ensemble du principe de l’algorithme. La
« réécriture » semble être dirigée plus par la volonté de justifier la méthode de développement que par la transmission, au travers d’une algorithmique classique, d’une méthode de solution qui, au-delà de l’algorithme, peut être récupérable dans un autre contexte (le tas permet d’introduire la notion de liste prioritaire).
L’approche est différente dans le Literate Programming de Knuth (Knuth, 1984) : le programmeur doit fournir un texte explicitant le raisonnement suivi lors de la conception de l’algorithme ; l’algorithme est présenté comme une séquence de
« morceaux » qui pourraient reconstituer l’historique de sa conception. En respectant quelques règles syntaxiques relativement peu contraignantes, le programmeur compose un texte qui sera traité par le système pour lui fournir deux documents séparés, d’une part, le texte d’explication de la conception, et d’autre part, un programme dans un langage de programmation donné. La qualité de l’explication du raisonnement dépend de ce que le programmeur veut bien écrire ; l’utilisation de la méthode ne garantit pas automatiquement que le texte aura une quelconque valeur explicative. Le système est là pour permettre à ceux qui acceptent d’exposer clairement les étapes de la conception de bénéficier de deux produits finis : un texte clairement mis en page et un programme. Le fait de n’imposer a priori aucune méthode spécifique de développement est le point fort du système : il n’implique, de la part du programmeur, que d’adhérer à l’idée d’expliciter son raisonnement. D’une certaine manière, le programmeur expose au lecteur son argumentation, sa justification de l’exactitude de la solution qu’il développe. Il n’est pas lié à l’obligation de prouver formellement son développement, mais seulement à l’obligation d’expliciter sa démarche. Le document qui en résulte devrait permettre au lecteur de porter un jugement sur la qualité du développement.
Il faut cependant constater que, malgré plusieurs décennies de réflexions et d’études sur la méthodologie de la programmation, il est bien difficile de délimiter un ensemble de méthodes qui pourraient être qualifiées de fondamentales et que ne pourrait ignorer un étudiant qui termine un premier cours en algorithmique. Nous n’avons toujours pas l’équivalent de méthodes « point de départ » qui peuvent être tentées pour aborder la résolution des problèmes ; nous voulons parler de méthodes qui joueraient un rôle similaire à, par exemple, les notions du « schéma du corps libre » (free-body diagram) ou de la règle de Kirchhoff dans les cours de physique.
C’est probablement la plus grande faiblesse du domaine : nous n’avons aucun accord parmi les spécialistes sur une méthodologie intermédiaire entre prouver formellement l’exactitude d’un programme et déboguer par essais et erreurs. Nous exposons à nos étudiants ce que nous pensons qu’ils peuvent tolérer de la première méthode, mais nous savons pertinemment qu’ils pratiquent surtout la deuxième, comme beaucoup de nos collègues d’ailleurs.
Bibliographie
Alain, Propos, La Pléiade NRF, Paris, 1956, 1370 p.
Backhouse, R., Program Construction - Calculating Implementations from Specifications, Wiley, 2003, 340 p.
Cohen E., Programming in the 1990s: An Introduction to the Calculation of Programs, Springer-Verlag, Texts and Monographs in Computer Science, 1990, 265 p.
Dijkstra E. W., A Discipline of Programming, Prentice-Hall, 1976, 217 p.
Dijkstra E. W., Feijen W. H. J., A Method of Programming, Addison-Wesley, 1988, 188 p.
Floyd R. W., « Toward interactive design of correct programs », Proceedings of IFIP Congress 1971, North-Holland 1972, p. 7-10.
Gries D., The Science of Programming, Springer-Verlag, Texts and Monographs in Computer Science, 1981, 366 p.
Gries D., Schneider F. B., A Logical Approach to Discrete Math, Springer-Verlag, Texts and Monographs in Computer Science, 1993, 497 p.
Kaldewaij A., Programming: The Derivation of Algorithms, Prentice-Hall, 1990, 216 p.
Knuth D. E., Literate Programming, The Computer Journal, Vol. 27, N°2, mai 1984, p. 97-111.
Knuth D. E., The Art of Computer Programming, Volume 1 : Fundamental Algorithms, Third Edition, Addison-Wesley Longman, 1997, 650 p.
Knuth D. E., The Art of Computer Programming, Volume 3 : Sorting and Searching, Second Edition, Addison-Wesley Longman, 1998, 780 p.
Knuth D. E., Robert W Floyd, In Memoriam, ACM SGACT News, Vol. 34, N°4, 2003, p 3-13.
Van den Snepscheut J. L. A., What Computing is All About, Springer-Verlag, Texts and Monographs in Computer Science, 1993, 478 p.
P.-A. de Marneffe Institut Montefiore Université de Liège 2#FG/CTPGHHG"WNICEDG
