Proximités et distances : pour une histoire des mathématiques assistées par l’ordinateur

Piste rouge Le 20 juillet 2015  - Ecrit par  Liesbeth De Mol Voir les commentaires (1)

Quel profit une histoire des mathématiques assistées par ordinateur peut-elle tirer de l’histoire de l’informatique ? L’évolution de la programmation ouvre-t-elle des voies nouvelles à l’histoire des mathématiques ?

Cet article est issu d’un exposé au Séminaire d’histoire des mathématiques de l’Institut Henri Poincaré dont la séance du 23 mai 2014 était consacrée aux interactions entre histoire des mathématiques et (histoire de) l’informatique.

Dans les textes philosophiques consacrés aux mathématiques assistées par l’ordinateur, [1] on lit souvent que, en principe, il n’y a pas de différence fondamentale entre les mathématiques élaborées avant et après l’avènement de l’ordinateur, le seul changement étant la vitesse des calculs, c’est-à-dire un changement purement quantitatif. [2] Mais cet argument, qui néglige le travail et le calcul investis par l’homme et la machine dans des problèmes mathématiques, méconnaît la « pratique ». [3] Sans examen de la « pratique », on ne peut en effet bien poser la question de l’impact de l’ordinateur sur les mathématiques. Si l’on veut aborder cette question, on a besoin d’une histoire des mathématiques qui rende compte de ces pratiques. Or celles-ci s’ancrent non seulement dans l’histoire des mathématiques mais aussi dans celle de l’informatique. Il nous faut donc une histoire des mathématiques qui soit ouverte à l’histoire de l’informatique.

En informatique, les pratiques se développent en partie par des interactions (directes ou indirectes) avec la machine. Ces interactions changent dans le temps, parce qu’elles passent par la technique de la programmation et la machine qui se sont développées et transformées au fil de l’histoire de l’ordinateur. Ainsi, pour faciliter le travail de l’utilisateur, la communication symbolique avec la machine doit notamment s’éloigner de la machine (langage de programmation, interface conviviale, etc.).

GIF - 277.7 ko
L’ENIAC

Commençons par l’un des premiers ordinateurs, l’ENIAC, rendu public en 1946 [4]. Cet ordinateur était un vrai « mastodonte » par sa taille, mais aussi par sa méthode de programmation originelle [5] : il n’offrait aucune interface symbolique de programmation. Ainsi, programmer c’était (re)câbler. Le temps requis pour les tâches de bas niveau dans la préparation des programmes était disproportionné par rapport au temps de la mise en œuvre effective des algorithmes - c’est ce que l’on appelle le goulot d’étranglement de la programmation [6] [7].

Même les machines déjà plus « programmables » qui ont immédiatement succédé à l’ENIAC n’étaient pas programmables au sens moderne. C’est-à-dire, on n’avait pas encore des compilateurs et, par conséquent, pas ce qu’on appelle des langages de haut niveau comme, par exemple, Lisp ou C. Les utilisateurs des ordinateurs étaient ainsi très proches du matériel informatique, ce qui se traduisait par des conceptions explicitement centrées sur la machine. Douglas Hartree, un « pionnier de l’informatique », disait ainsi (Hartree, 1949) :

Quand on programme un problème pour la machine, il faut voir les instructions opératoires « à travers les yeux de la machine » , c’est-à-dire les regarder depuis le point de vue de la machine qui ne peut les suivre que littéralement, sans rien introduire qui n’ait été explicitement stipulé par elles, et essayer de prévoir toutes les choses inattendues qui peuvent arriver au cours du calcul et de fournir à la machine les moyens d’identifier ces choses en étant munies d’instructions opératoires appropriées à chaque cas. [8]

C’est à la fin des années 1950 et au début des années 1960, une fois développée la technique de la compilation, qu’il devint possible de « programmer » au sens moderne, c’est-à-dire d’utiliser un langage de programmation de haut niveau.

JPEG - 65.3 ko
Reconstruction d’un câblage d’une partie d’un programme sur l’ENIAC (voir Bullynck M. et De Mol L., 2010 pour plus de détails)

D’ailleurs, la compilation permet d’écrire un programme dans un « langage » qui est plus « facile » à utiliser du point de vue de l’humain et qui est traduit automatiquement dans le « langage » de l’ordinateur. Ces développements, ainsi que les progrès dans la technologie de la mémoire électronique, ont rendu possible l’intériorisation progressive des processus de calcul dans la machine, [9] permettant l’émergence de différents niveaux d’abstraction par rapport au matériel informatique, établissant ainsi une certaine distance entre l’utilisateur et la machine. De plus, les machines des années 1950 et 1960 étaient des grosses unités centrales (mainframes) appelant des pratiques particulières : les utilisateurs des machines n’étaient pas les opérateurs des machines. C’est-à-dire que si on voulait utiliser la machine, on préparait un programme sur un formulaire (coding form) qui était préparé par l’opérateur et perforé sur des cartes pour l’exécution sur la machine. Ainsi, l’interaction entre utilisateur et machine n’était qu’indirecte. Cette situation commença à changer avec le développement de la technique du « temps partagé » dans les années 1960, technologie qui permet l’utilisation de la machine par des utilisateurs multiples.

JPEG - 58.6 ko
Exemple d’un programme dans FORTRAN préparé sur un formulaire (coding form) pour l’opérateur d’un IBM 704 qui le « traduisait » sur une carte perforée pour l’exécution.

Dans les années 1970 et 1980 on voit les interfaces évoluer pour toucher le grand public avec l’idée des interfaces conviviales (user-friendly) qui accompagnent le développement de l’ordinateur personnel. Car l’idée même de ces interfaces est de créer quelque chose que tout le monde peut utiliser, de dissimuler tous les aspects techniques de la machine et d’intérioriser des fonctions sous-jacentes, comme le traçage d’un cercle ou la recherche d’un mot dans un document. On voit donc, après les années pionnières de l’ordinateur, une tendance à s’abstraire de la machine et à intérioriser les processus de calcul dans la machine. Ainsi, en s’éloignant de la machine pour créer des interfaces orientées vers (et taillées pour) l’utilisateur on confie aussi plus de responsabilités à la machine.

JPEG - 117.6 ko
Animation d’une tâche typique sur un superordinateur (mainframe) où le programmeur n’a pas un accès direct à l’ordinateur. L’IBM 704 pour lequel Backus développa FORTRAN est l’un de ces anciens superordinateurs.

Cependant, un autre mouvement accompagne le processus d’intériorisation. [10] D’un certain point de vue, nous sommes aujourd’hui beaucoup plus proches de la machine que dans les années 1950 et 1960, car nous avons tous un accès direct à des machines, rendu possible par l’ordinateur personnel. [11]

JPEG - 56.3 ko
Le PDP-1, la machine utilisée pour le développement du premier système commercial à temps partagé.

Ce mélange de distance et de proximité fait que les interactions entre les utilisateurs et leurs machines sont, dans les pratiques scientifiques liées à l’ordinateur, très complexes.

JPEG - 16.2 ko
Exemple d’un programme en Scheme, un langage de programmation fonctionnel.

Le développement des relations entre êtres humains et machines que nous avons esquissé ici a aussi eu un effet dans les mathématiques.

JPEG - 14.6 ko
Le système 1 de Apple, l’un des premiers systèmes d’exploitation conviviaux commercialisés.

Un exemple concret est la disparition des tables numériques comme aide au calcul humain et le développement des tables numérisées, qu’elles soient visibles ou invisibles, et des algorithmes qui remplacent ces tables. [12] Évidemment, on ne peut pas réduire ces développements à des processus d’intériorisation, mais ils jouent un rôle important dans ce processus historique et on ne peut l’observer que si l’on inclut cet aspect de l’histoire de l’informatique.

JPEG - 4.7 ko
Le Macintosh 128K livré avec le système 1.

En général, cette perspective nous donne une manière d’étudier des changements dans les pratiques des mathématiques assistées par l’ordinateur que l’on ne pourrait pas observer si l’on réduisait le rôle de l’informatique. Quelques questions historiques s’inscrivent ainsi dans cette approche :

  • Peut-on identifier des méthodes particulières et des communautés spécifiques autour des différents langages et matériaux ? Par exemple, Lehmer, qui travaillait sur la théorie des nombres et favorisait une approche explorative, n’a jamais apprécié le développement des langages de programmation de haut niveau. Il écrit en effet :

Le problème du langage est crucial. Des langages comme ALGOL et FORTRAN se tiennent entre l’utilisateur et la machine pour « l’aider à communiquer ». Bien sûr, l’utilisateur en question n’est jamais un spécialiste de théorie des nombres. Nul besoin d’avoir des années d’expérience pour découvrir que beaucoup de problèmes de théorie des nombres ne deviennent accessibles que si l’on a accès à la totalité des instructions machine du langage propre à la machine.[(Lehmer, 1969) [Texte original : « The language problem is a case in point. Languages like ALGOL and FORTRAN stand between the user and the machine to “help him communicate.” [O]f course, the contemplated user is never a number theorist. [I]t doesn’t take years of experience to discover that many number theory problems are made feasible only by having access to the full repertory of the machine’s instructions in the machine’s own language."]]

Ainsi, les intérêts et méthodes spécifiques de Lehmer déterminaient aussi ses préférences au niveau des machines et des langages de programmation. De la même façon mais en contraste avec Lehmer, un mathématicien comme Gonthier, qui travaille sur des preuves formelles [13], comme par exemple sa preuve du théorème des quatre couleurs (Gonthier G., 2008), a besoin des langages de haut niveau en utilisant des assistants de preuve comme Coq.

  • En quoi les façons de programmer (la programmation proche de la machine ou conviviale ; formelle ou numérique ; fonctionnelle ou orientée objet, etc.) influent-elles sur les notations et les descriptions des algorithmes qu’on peut identifier dans le discours des mathématiciens ?
  • Quel est l’effet des logiciels comme Maple et Mathematica, qu’on peut considérer comme des logiciels conviviaux pour les mathématiciens et qui unifient différents outils en un système ? Par exemple, ce n’est peut-être pas par hasard qu’une recherche systématique sur les mathématiques expérimentales s’est récemment développée autour de Maple, et que Wolfram a proposé sa grande théorie des sciences (« a new kind of science  »), ancrée dans une méthode exploratoire, après avoir développé Mathematica.
JPEG - 201.2 ko
Exemple d’un programme en Maple.
  • Quelles mutations peut-on observer dans la représentation des données (c’est-à-dire des visualisations, des tables, des graphiques etc.) ?

Ces questions indiquent ce que peut être le rôle d’une histoire de l’informatique dans ce contexte. Mais les raisons d’étudier l’histoire des mathématiques à l’époque de l’ordinateur ne sont pas seulement historiques : elles sont aussi politiques. Le mathématicien Joris van der Hoeven disait ainsi :

En tant que mathématicien, j’ai la conviction profonde que seuls les logiciels libres sont acceptables d’un point de vue scientifique. J’y vois deux raisons principales :

  • un résultat calculé par un système « mathématique », dont le code source n’est pas public, ne peut être accepté comme élément d’une démonstration mathématique ;
  • de même qu’un mathématicien devrait être capable de construire des théorèmes en s’appuyant sur d’autres théorèmes, il devrait être possible de modifier et de distribuer les algorithmes d’un logiciel mathématique.

À l’inverse, il est étrange et malheureux que les principaux programmes mathématiques actuellement d’usage courant soient propriétaires. La principale raison de ce fait est que les mathématiciens ne considèrent généralement pas la programmation comme une activité scientifique à part entière. Par conséquent, le développement de logiciels utiles est délégué à des « ingénieurs » et le résultat est utilisé comme des boîtes noires. [14]

D’ailleurs, le fait que les logiciels conviviaux préférés dans les mathématiques, comme Maple ou Mathematica, [15] soient propriétaires, et que la partie invisible de ces programmes ne soit pas accessible pose des problèmes fondamentaux pour les mathématiques, problèmes qui sont ancrés dans le procès historique d’intériorisation, la perspective centrée sur l’utilisateur et le fait que ces logiciels soient accessibles au grand public. Le double enjeu des distances et des proximités que j’ai esquissé ici crée une situation critique pour les mathématiques, qui demande une réflexion profonde sur ces outils numériques. En étudiant l’histoire de cet enjeu et l’effet de cette perspective sur les mathématiques, on peut espérer en tirer, pour le moins, une compréhension des problèmes nés de ce processus.

Bibliographie

Abelson, H., Sussman, G.J. Et Sussman, J. (1996), Structure and Interpretation of Computer Programs, MIT : Cambridge, Massachusetts.

Backus, J. et al, Fortran. Automatic Coding System for the IBM 704, 1956.

Bullynck, M. et De Mol, L. (2010), Setting-up early computer programs : D.H. Lehmer’s ENIAC computation, Archive for Mathematical Logic, vol. 49, nr. 2, pp. 123—146.

De Mol L, Bullynck M. et Carlé M (2010), Haskell before Haskell. Curry’s contribution to programming (1946-1950), Ferreira F, Loewe B. et al (éds.), Programs, Proofs, Processes, Lecture Notes in Computer Science, vol. 6158, pp. 108-117.

De Mol L. et Durand-Richard, M.-J., Calculating Machines and Numerical Tables. A reciprocal history, dans : D. Tournès, History of Numerical Tables, Springer, à paraître.

Gonthier, G. (2008), Formal Proof - The four-color theorem, Notices of the AMS, vol. 5, nr. 11, pp. 1382-1393.

Haigh, T., Priestley, M. et Rope, C. (2014), Engineering “The mircale of the ENIAC” : implementing the moden code paradigm, IEEE Annals for the history of computing, vol. 36, nr. 2, pp. 41—59.

Hales, Th., Harrison, J. et al, (2010), A revision of the proof of the Kepler conjecture, Discrete and Computational Geometry, vol. 44, pp. 1-34.

Hartree, D. (1949), Calculating instruments and machines, The University of Illinois Press.

Lehmer, D.H. (1969), Computer technology applied to the theory of numbers, Studies in Number Theory, MAA Stud. Math. 6, pp. 117–151.

Stephen Wolfram (2002), A new kind of Science, Wolfram Media.

Post-scriptum :

Pour en savoir plus, n’hésitez pas à visionner en ligne la captation audiovisuelle de cette séance du Séminaire d’histoire des mathématiques de l’IHP.

L’auteure remercie Baptiste Mélès pour sa relecture de ce texte, ses corrections et ses traductions des citations en anglais.

La rédaction d’Images des Mathématiques ainsi que l’auteure remercient les relecteurs Pierre Lescanne et Thomas Rataud pour leur relecture attentive.

Article édité par Frédéric Brechenmacher

Notes

[1Mathématiques assistées par l’ordinateur, ça veut dire ici l’utilisation de l’ordinateur dans la recherche même, par exemple, l’utilisation de Coq (voir cet article concernant ce logiciel) pour la preuve formalisée et vérifiée du théorème des quatre couleurs ou des calculs d’exploration liés à des conjectures. Je ne parle pas ici de l’utilisation des logiciels de composition des documents comme LaTeX ou l’utilisation de l’internet comme moyen de communication.

[2Ici, je me concentre seulement sur les discussions contemporaines sur l’impact de l’ordinateur moderne sur les mathématiques. Evidemment, l’ordinateur moderne n’est pas la seule type de machinerie qui a été utilisé en mathématiques. Des machines analogues comme l’analysateur differentiel de Hartree ou les machines de Babbage sont que quelques example. Ces machines joue aussi un rôle important dans le développement de l’ordinateur moderne (Voir par exemple. De Mol et Durand-Richard, à paraître

[3Ici je me concentre seulement sur les pratiques qui utilisent l’ordinateur comme outil de calcul (dans un sens large) et non pas sur l’utilisation de l’ordinateur comme outil de communication (p.e., courriel) ou outil de typographie (p.e. LaTeX). Ces utilisations font aussi parti des pratiques mathématiques, mais demandent une autre analyse.

[4L’histoire de l’ENIAC commence en 1943 quand l’armée des Etats-Unis décidait de financer la proposition de Eckert et Maucly, deux ingénieurs, de construire une machine électronique pour calculer des tables numériques.

[5En 1948 l’ENIAC fut recâblé de façon à permettre une forme primitive de communication symbolique (voir Haigh, Priestley et Rope, 2014).

[6En Anglais on parle de « programming bottleneck ». Ce terme a ses origines dans les travaux de Haskell Curry sur l’ENIAC et sa théorie de la programmation. Voir De Mol L., Bullynck M. et Carlé M. (2010) pour plus de détails.

[7Évidemment, on peut encore de nos jours investir dans la programmation un temps disproportionné par rapport au temps de l’exécution. Mais on n’a plus besoin de tout spécifier à la machine ce qui permet d’écrire des programmes bien plus longs et plus complexes.

[8Texte original : « [I]n programming a problem for the machine, it is necessary to take a “machine’s-eye view” of the operating instructions, that is to look at them from the point of view of the machine which can only follow them literally, without introducing anything not expressed explicitly by them, and try to foresee all the unexpected things that might occur in the course of the calculation, and to provide the machine with the means of identifying each one and with appropriate operating instructions in each case. »

[9L’intériorisation désigne le processus par lequel une fonction est (pré)programmée dans la machine, l’utilisateur n’ayant besoin de connaître que les actions requises. Je donne quelques exemples : ouvrir un document par double-cliquer sur une icône ; factoriser un nombre dans Maple, utilisant « ifactor(n) ».

[10Je suis redevable à Catherine Goldstein pour avoir remarqué que le processus de prise de distance n’est pas nécessairement progressif et que, en fait, aujourd’hui il y a moins de distance physique entre les machines et ces utilisateurs.

[11Aujourd’hui on peut observer une ré-introduction des distances physiques, par exemple par le nuage digital et les réseaux sociaux avec lesquels on donne le contrôle sur ses données personnelles à des entreprises comme Google ou Facebook pour utiliser ces services « gratuitement ». La différence avec les années 1950 et 1960 est que l’on vit aujourd’hui dans l’illusion d’une proximité et ainsi d’un contrôle sur ces données que l’on peut stocker, échanger et télécharger directement sans traverser une distance et un temps physiques pour y accéder.

[12De Mol et Durand-Richard, à paraître.

[13Une preuve formelle est une preuve pour laquelle chaque inférence logique a été vérifiée. La définition vient de Hales, Th., Harrison, J. et al, (2010) : « A formal proof is a proof in which every logical inference has been checked, all the way back to the foundational axioms of mathematics. No step is skipped no matter how obvious it may be to a mathematician. A formal proof may be less intuitive, and yet is less susceptible to logical errors. Because of the large number of inferences involved, a computer is used to check the steps of a formal proof. ». Hales a travaillé plusieurs années sur la formalisation et donc vérification de sa preuve originale de la conjecture de Kepler

[14Texte original : "As a mathematician, I am deeply convinced that only free programs are acceptable from a scientific point of view. I see two main reasons for this :
• A result computed by a “mathematical” system, whose source code is not public, can not be accepted as part of a mathematical proof.

• Just as a mathematician should be able to build theorems on top of other theorems, it should be possible to freely modify and release algorithms of mathematical software.

However, it is strange, and a shame, that the main mathematical programs which are currently being used are proprietary. The main reason for this is that mathematicians often do not consider programming as a full scientific activity. Consequently, the development of useful software is delegated to “engineers” and the resulting programs are used as black boxes."

[15Heureusement, il y a aussi des logiciels libres comme Sage.

Partager cet article

Pour citer cet article :

Liesbeth De Mol — «Proximités et distances : pour une histoire des mathématiques assistées par l’ordinateur» — Images des Mathématiques, CNRS, 2015

Crédits image :

img_14234 - Dartmouth Time sharing System
img_14233 - Abelson et al, 1996
img_14232 - © Prentice-Hall
img_14231 - (FORTRAN, 1956)
img_14230 - (Bullynck et De Mol, 2010)

Commentaire sur l'article

  • Proximités et distances : pour une histoire des mathématiques assistées par l’ordinateur

    le 27 juillet 2015 à 17:20, par Lhooq

    Bonjour,

    J’ai une petite question relative à cette partie :

    C’est-à-dire, on n’avait pas encore des compilateurs et, par conséquent, pas ce qu’on appelle des langages de haut niveau comme, par exemple, Lisp ou C.

    Je ne vois pas en quoi la compilation est une condition nécessaire pour qu’un langage soit considéré comme « de haut niveau ».

    Ce problème que j’ai tient en deux points :

    • Il existe des langages interprétés de haut niveau

    Exemple

    Lisp en est un parfait exemple puisque cette famille de langage est connue pour être interprétée

    • Il existe des langages compilés de bas niveau

    Exemple

    Les langages assembleurs sont parfois compilés pour correspondre à des instructions machines ou, dans une autre mesure, le langage C est considéré par beaucoup comme un langage de bas niveau alors qu’il est compilé

    Ai-je mal compris votre énoncé ou n’ai-je rien compris à l’informatique ? ;-)

    Cordialement,

    Lhooq

    Répondre à ce message

Laisser un commentaire

Forum sur abonnement

Pour participer à ce forum, vous devez vous enregistrer au préalable. Merci d’indiquer ci-dessous l’identifiant personnel qui vous a été fourni. Si vous n’êtes pas enregistré, vous devez vous inscrire.

Connexions’inscriremot de passe oublié ?

Suivre IDM