au sommaire
Le calcul sur machine : merveilles et canulars
Les ordinateursordinateurs ont envahi notre quotidien, pour accomplir des tâches répétitives ou « managériales » qui n'ont rien de scientifique, mais aussi pour seconder l'esprit de qui entreprend une modélisation quantitative sous une forme ou sous une autre.
Ces machines prodigieuses permettent de calculer et de concevoir des objets d'une telle complexité que sans les computers, petits ou gros, aucun d'entre eux n'aurait vu le jour (qu'il s'agisse d'Ariane, du LHC... ou des supercalculateurs), et aussi et surtout de répondre à des questions fondamentales qui, sans ces moyens extraordinaires, seraient restées sans réponse.
La fascination que l'on éprouve à juste titre devant ces machines ne doit pas faire oublier que ce ne sont que des « outils » qui ne remplaceront jamais les quelques milliards de neuronesneurones bien connectés d'individus fonctionnant massivement en parallèle. Ce rappel est d'autant moins inutile que l'on voit surgir et se développer des tendances stupéfiantes, et nuisibles, comme celles voulant évacuer de l'enseignement des mathématiques quelques-uns de ses fondamentaux au motif (stupide) que les machines savent aujourd'hui faire des opérations très sophistiquées. Me croira-t-on quand j'affirme avoir entendu la suggestion de supprimer l'intégration des programmes puisque n'importe quel ordinateur est capable de calculer des intégrales (enfin, certaines) ?
© De Boeck
Passons sur le fait que même les logicielslogiciels de calcul formel les plus élaborés restent souvent incapables de répondre à des questions qu'un étudiant ayant appris l'analyse complexe traite en quelques minutes. Passons aussi sur le fait que, souvent, on cède à la tentation d'utiliser des codes dont on ne sait rien, jetant en pâture à une boîte noire un flot d'informations qu'elle ne peut digérer machinalement que comme on lui a dit de le faire pour sortir des résultats bruts, dont toute analyse critique se trouve de ce fait impossible.
Il y a plus grave, fondamentalement, car ces machines, elles non plus, ne connaissent ni le zéro ni l'infini. Forcément. Peut-on demander à une machine d'effectuer une « infinité » d'opérations en un intervalle de temps « fini » ? De prendre en compte « toutes » les décimales de π (que l'on ne connaît d'ailleurs pas) ou celles de √2 ? Non, évidemment, tout éblouissantes qu'elles soient, ces machines ne savent pas, plutôt, elles ne peuvent pas. 1,414213562373095048 ne sera jamais égal à √2, pas plus que 22/7 n'est égal à π.
Grave, pas grave ? Cela dépend, et l'on retombe alors sur la question abordée dans la section précédente : chaos, pas chaos ? Il y a des cas où c'est sans conséquence, mais ce sont aussi souvent ceux où le problème n'a pas la complexité suffisante pour contenir, tapi dans un recoin, un virus qui n'a rien d'informatique, prêt à s'activer, ou en tout cas n'est pas impossible à détecter grâce à l'analyse faite avec un crayon, une gomme, un bout de papier et une bonne maîtrise des mathématiques appliquées.
C'est au contraire dans les cas difficiles (du moins en principe) que l'on recourt au calcul automatique, formel ou numériquenumérique. Et là, tout peut arriver, y compris dans des situations d'apparence simple où, justement, on peut constater après avoir fait le calcul à la main en faisant fonctionner sa tête, que la machine part dans le décor. Ce peut être parce que l'algorithme est inadapté à la question posée (mais pour le savoir, il faut plonger dedans), mais aussi plus fondamentalement en raison de l'impossibilité, justement, de représenter exactement certains nombres en machine. Aussi parce que le plus souvent, numériser c'est « discrétiser », et on a dit plus haut que la vision qui sort du continu n'a parfois rien à voir avec celle qui ne connaît que les nombres entiers (ou même les rationnels) -- encore l'alternative discret-continu !
L'impossibilité de donner à une machine une copie « exacte » des nombres est incontournable ; elle tient à la nature des choses, et au fait qu'il en existe qui s'invitent sans autorisation, π, la constante γ d'Euler, les constantes δ et α de Feigenbaum, et mille autres curiosités que l'on ne sait représenter « exactement » que par un symbole spécifique qui ne dit rien, strictement rien, à une machine. Elle est bien sûr l'objet de recherches avancées dans les milieux de l'informatique théorique, afin de déjouer les pièges ou en tout cas d'installer suffisamment de pare-feux pour éteindre l'incendie s'il venait à se déclarer. Laissant cette question très difficile aux experts en la matière, on se doit toutefois de montrer par l'exemple (un exemple suffit !) jusqu'à quelle folie -- ici sans conséquence pratique, pas de catastrophe nucléaire, pas de crash d'avion -- une machine pas trop bien encadrée peut nous entraîner.
C'est pourquoi il faut renvoyer à un superbe article (très lisible) de Jean-Michel Muller [voir note en bas de page, NDLRNDLR] que j'ai discuté dans mon livre (Claude AslangulClaude Aslangul, Des mathématiques pour les sciences, De Boeck, Bruxelles, 2011, p. 779) et détaillé dans le problème 16.7.10, concernant une application itérative non linéaire (tiens, tiens) du second ordre. Tous les ingrédients sont réunis, mais, là encore, un collégien n'aurait aucune peine à calculer les premiers termes, puisque l'énoncé du problème est élémentaire. L'analyse détaillée (exclusivement avec son crayon) permet de comprendre pourquoi, sans prendre de précaution, on obtient à toute vitesse un résultat désastreux, au sens où un code naïf fournit en quelques itérations une solution en totale contradiction avec le déterminisme absolu auquel pourtant l'itération est assujettie. La raison en est que ce problème, pourtant simple, possède une sensibilité aux conditions initiales (coucoucoucou, la revoilà) et que les erreurs d'arrondi font diverger la trajectoire calculée par rapport à la trajectoire exacte. Pour obtenir celle-ci, il faut travailler exclusivement en nombres entiers, c'est-à-dire ne pas mettre un « . » aux valeurs entrées au clavierclavier pour fixer le point de départpoint de départ -- taper « 3 », surtout pas « 3. ». Et pourtant, 3 n'est-il pas égal à 3,000000 000... (autant de décimales que la machine peut en absorber) ? Bien sûr que si, mais 1/3 n'est pas égal à 0,333333333333 (on s'arrête là). Un détail.
Sans doute, la meilleure façon de donner l'envie d'en savoir plus est de citer cet auteur dans l'une de ses conclusions : « On observe parfois en machine une bonne et rapide convergence vers un résultat totalement faux. »
Quoique contenant évidemment ce qu'il faut pour la démonstration, l'exemple de Muller est en fait assez simple pour que l'on puisse effectivement le résoudre complètement avec un peu d'algèbre et de savoir-faire, dénichant ainsi les endroits où se tiennent les défaillances, pour ne pas dire les vices, d'une procédure numérique trop rapidement élaborée. Mais alors, justement dans les cas où il est réellement impossible d'avoir une idée précise à l'avance en raison de l'immense complexité du problème, qu'elle soit dans la nature de celui-ci ou dans l'horreur des équationséquations qui le modélisent, que penser, que croire, que faire ?
La règle méthodologique s'impose d'elle-même : commencer par acquérir de solidessolides connaissances en mathématiques (appliquées), les seules qui permettent de débrouiller le problème à la main en le dégrossissant au maximum, analyser les cas limites pour voir comment retomber sur ses pieds, et non pas la tête en l'airair, bref, baliser la route, ordinateur éteint.
Et alors seulement, seulement après tout cela, appuyer sur le bouton on.
Note
Jean-Michel Muller, Ordinateurs en quête d'arithmétique, La Recherche, 278 (numéro spécial sur la théorie des nombres), p. 772, juillet-août 1995.
