Les langages de la modélisation

Le premier langage de programmation de la modélisation fut le Fortran, mais compte tenu de ses défauts (Label GOTO, déclaration implicite, chaînes de caractères laxistes, ab-sence de récursivité, etc.) des langages plus proches de l’algorithmiques furent par la suite créés (Algol). Presque simultanément, sont apparus des macrolangages – i.e. des langages eux-mêmes programmés dans un langage évolué31, tandis que GAMS permet d’effectuer de la recherche opérationnelle et des microsimulations. Le marché du logiciel s’est très largement étoffé depuis ces trente dernières années. Sas, Rats, Gauss, Soritec permettent d’effectuer des travaux économétriques. Troll, Census X11, SPSS, SAS, Simsys, Moduleco, G, MODGEN permettent d’effectuer des travaux de modélisation

32.

Tous ces logiciels - c’est également le cas de notre logiciel SIMUL - requiert l’utilisation d’instructions spécifiques qui sont ensuite traduites par le système [170, 181, 188, 195]. L’intérêt de tels logiciels est, moyennant une contrainte d’apprentissage, d’obtenir des résultats assez facilement et rapidement. Toutefois, dans certains cas très limités, le re-cours à des langages évolués, voire à des tableurs, peut s’avérer rentable. Dans ces cas, il faut alors choisir le langage adéquat. Le langage C/C++ présente l’avantage de géné-rer un code très rapide. En d’autres termes, C est le langage évolué le plus proche de l’assembleur33. Pascal, C et Fortran 90 et suivants sont des langages structurés (il n’y a plus d’étiquettes GOTO) lisibles et qui permettent d’implémenter aisément les principaux algorithmes de l’analyse numérique. En dépit des normes internationales IEEE la plupart des éditeurs semblent faire évoluer leurs langages Fortran, Basic ou Pascal vers le langage C/C++ ou Java. Les applications en Lisp sont possibles, à condition d’accepter un trai-tement interprété (tous les Lisp ne sont pas compilés). Le champ d’application est celui du calcul symbolique – les logiciels de calculs formels (par ex. : Dérive) sont construits en Lisp. Bien que Prolog III se proposait de résoudre des systèmes d’équations, son utilisation 31. - Il faut distinguer les langages de simulation continue - Dynamo, Stella, Neptunix, Vensim - des langages de simulation discrète - Cadence, GPSS, Q-GERT, Simscript, Simula, SLAM, Q-NAP ([886], pp.93–111). Actuellement, sans livrer une liste exhaustive des logiciels disponibles, disons que Matlab, Maple permettent d’effectuer des manipulations formelles [166, 168, 169], nous évoquions la pertinence des logiciels du type solveur (Eureka, Prosolveur, etc.), mais depuis les logiciels de calcul formel sont apparus, rendant moins utiles les solveurs.

32. - Les tableurs ne sont pas proscrits a priori de modélisation dans la mesure où ils disposent d’un langage de programmation proches de ceux cités précédemment [696].

33. - Les langages tels que Fortran et Pascal par exemple, comportent dans leurs instructions des redondances qui ralentissent l’exécution de celles-ci. L’utilisateur n’y peut absolument rien, dans la mesure où ces redondances sont inhérentes au traitement des instructions par le compilateur. Borland a essayé de corriger ce défaut dans le Turbo-Pascal notamment concernant la boucle REPEAT. La nouvelle instruction d’incrémentation SUCC(i) est nettement plus performante que i :=i+1.

exclusivement pour de l’analyse numérique nous paraît peu rentable en termes d’inves-tissement ; Lisp et Prolog exigent plus qu’un apprentissage des instructions. En tout état de cause, quasiment tous les langages ont adopté des versions orienté objet, or "le très

haut niveau d’expression offert par les langages orientés objet permet des applications très performantes en simulation" ( [616], p.173). L’examen des logiciels professionnels est

riche d’enseignement. On constate une prédominance du langage C/C++ [174], mais le champ des logiciels s’est élargi avec l’apparition de langages spécifiques pour la program-mation de logiciels de navigation sur Internet ; on trouve désormais les langages HTML, Java et JavaScript. Cet examen des langages et des macro-langages de programmation nous a permis de denombrer sept critères de choix de langages de programmation pour la modélisation [174] réactualisé – voir Tab. 3.1 et 3.2 :

1˚ - Lisibilité - Plus les instructions sont évoluées – i.e. compréhensibles – plus le

programme se présentera sous une forme proche de l’algorithme mathématique à l’origine du programme – citons pour cette qualité les logiciels statistiques et solveurs, ainsi que l’APL (modèle ICARE, [507]) et les langages évolués Fortran et Pascal34

2˚ - Capacité mémoire - La capacité mémoire de base de la machine est

générale-ment utilisée par tous les logiciels ou langages ; certains permettent en outre l’accès aux extensions- mémoire - citons les tableurs, et les langages-machine (Assembleur), ou les langages évolués à mémoire adressable (Pascal, langage C) [895, 769].

3˚- Rapidité d’exécution - Les langages proches de celui de la machine (Assembleur)

ou à "code optimisé" (langage C) permettent une plus grande rapidité d’exécution ; les Tableurs conservent cette qualité. Cependant plus les instructions sont lisibles, plus elles risquent de perdre en rapidité.

4˚ - Portabilité - Les logiciels ne nécessitant pas l’utilisation de leur propre système

pour être utilisables, sont dits "portables". Ainsi, les langages interprétés – i.e. traduits puis exécutés – (Basic, APL), ou intégrés à un système (Excel) perdent cette qualité alors que les langages compilables (Fortran, Pascal, C), ne requiert plus leur logiciel de compilation une fois traduit en code. Les logiciels statistiques sont "pseudo-portables" (Rats, SPADN) bien que non compilés.

5˚ - Transparence - Cette propriété consiste à rendre disponibles toutes les valeurs

des variables à chaque phase de calculs. Les tableurs et les logiciels statistiques ignorent cette possibilité, surtout lorsqu’ils utilisent toute la capacité de mémoire notamment avec les overlays – i.e. le même espace mémoire alternativement est partagé entre plusieurs variables dont l’utilité n’est pas jugée simultanément pertinente. Tous les langages de programmation (sauf l’APL) sont transparents.

6˚ - Accessibilité - C’est la structure de la banque de données et le format des

ré-sultats qui confèrent la qualité d’accessibilité aux logiciels. Ainsi, Tableurs et Solveurs sont limités, alors que les logiciels de statistique et de modélisation ainsi que les langages permettent à des degrés divers - notamment en recourant à un codage du format plus ou moins souple l’accès à diverses structuration de banques.

7˚ - Interface graphique - C’est davantage la machine que le logiciel qui détermine

cette propriété [329]. Il faut signaler toutefois que les tableurs offrent un jeu assez "sté-réotypé" de graphiques, et que certains langages restent encore assez frustres à cet égard. L’adoption de l’interface Windows ou X-Windows sous Unix tend à atténuer ce défaut.

Lisibilité Mémoire Rapidité Portabilité Transparence Accessibilité Graphique

Assembleur * *** *** *** *** ** *** Basic ** ** ** * *** *** *** Fortran ** ** ** *** *** *** * Pascal *** *** ** *** *** *** *** C/C++ ** *** *** *** *** ** *** Java *** *** ** ** * *** ** APL *** ** ** * ** ** * Tableurs ** *** ** * ** * ** Solveurs *** *** ** ** ** * ** Logiciels *** *** ** ** * ** ***

Echelle d’évaluation : (*) = médiocre / (**) = moyen / (***) = bon

Tableau 3.1 – (Macro)Langages de programmation et modélisation (I)

Commentaires

Assembleur Adressage direct, optimisation du code et de l’accès à la mémoire

Basic Structuré et objet depuis Visual Basic

Fortran Structuré depuis la version 90, proche des algorithmes mathématiques, mais format encore pénible

Pascal Structuré, adressage direct - gain mémoire et vitesse -, proche de l’algorithme

C/C++ Structuré, adressage direct, types de variable souples, interface assembleur

Java Le langage des réseaux, mais interprété

APL Ecriture rapide et symbolique des algorithmes, intéressant en version compilée et modulable

Tableurs Structuré lorsque combinés à des langages tels que Visual Basic ; risque de ralentis sur plusieurs feuilles

Solveurs Lisible, peu transparent, entrées sorties très limitées ; semblent abandonnés

Le choix d’un langage du programmation des algorithmes à implémenter en modé-lisation macro-économique peut sembler secondaire au regard des problèmes macroéco-nomiques qui préccupent l’économètre, mais la question du "Faire ou faire faire ?" est d’autant plus importante qu’aucun modélisateur - à notre connaissance - n’a pu utili-ser un logiciel si intégré soit-il, tel quel – à propos de Simsys, voir [268]. Le choix de langage de notre logiciel s’est fait sur un arbitrage entre trois options [29, 438]. En premier lieu, conserver le langage Fortran, c’est-à-dire celui du modèle REGIS [248, 249], mais d’une part, les interfaces graphiques du Fortran étaient trop frustres, d’autre part le logiciel n’avait pas vocation à fonctionner exclusivement avec le modèle REGIS. Deuxiè-mement, conserver le langage utilisé pour développer le module d’estimation ESTIME, le Turbo-Pascal 7.0, au cours de notre travail de DEA [163]. Enfin, troisièmement, choisir un nouveau langage, le C ou Delphi en l’occurrence, ce qui aurait nécessité un nouvel apprentissage. C’est finalement le seconde option que nous avons choisie, qui n’interdit d’ailleurs pas un basculement ultérieur, vers le langage DELPHI. Toutefois, la tendance actuelle observée consiste à utiliser des langages – en particulier le langage R [356] – disposant de bibliothèques statistiques, matricielles et économétriques très souples.