2.4 Giac: une librairie de calcul formel en développement 

Présentation rapide de Giac/Xcas 

Giac est un projet de librairie C++ de logiciel libre de calcul formel (sous licence GPL) que j'ai démarré en 2000 à la suite du développement du logiciel de calcul formel intégré aux calculatrices graphiques HP49 et HP40¹ effectué pendant une délégation au sein de Hewlett Packard en 1998/99, xcas est le nom du programme avec interface graphique correspondant. J'ai écrit l'essentiel du code, Renée de Graeve ayant codé le reste et documenté l'essentiel de la documentation en-ligne, R. Kreckel a écrit la première version de l'autoconfiguration.

Giac a pour objectif de coordonner les efforts de développement libres en vue de créer un logiciel de calcul formel et géométrie dynamique utilisable aussi bien en recherche qu'en enseignement. Il existe un logiciel libre de calcul formel généraliste aujoud'hui: c'est maxima (en fait pas tout-à-fait libre car maxima utilise gnuplot pour la visualisation de fonctions et gnuplot contrairement à ce que le gnu de son nom pourrait laisser croire n'est pas un logiciel libre). Mais mon opinion est que son avenir n'est pas clair: il n'a malheureusement plus de maintainer officiel, mais ce qui est plus grave c'est qu'une grande partie de son code source est écrit en lisp peu ou pas commenté (sans parler des problèmes de taille, j'y reviendrai en parlant de financement plus loin). Il existe aussi une offre commerciale importante. Mais il me semble qu'on ne peut pas raisonnablement baser un résultat mathématique sur un calcul utilisant un logiciel dont les sources ne sont pas libres. D'autre part, les performances de certaines librairies libres par rapport aux logiciels formels généralistes sont très souvent bien meilleures dans leur domaine mais il manque à ces librairies une interface graphique unifiée et les assembler nécessite des compétences d'administration système pas forcément accessible dans tous les laboratoires de recherche et à fortiori pour un individu plus isolé.

De plus, la France dispose d'une importante communauté de recherche en calcul formel et est un des pays ou il est le plus utilisé dans l'enseignement (en particulier dans les lycées grace aux calculatrices graphiques symboliques). Pourtant nous n'avons jamais développé de logiciel de calcul formel (mettons à part PARI qui n'est pas généraliste). On a en effet l'habitude en France de considérer l'implémentation d'un logiciel comme n'étant pas de la recherche. Or les choix techniques sont aussi des choix politiques. Il faut garantir notre indépendance dans ce domaine (à défaut de pouvoir le faire aussi dans le domaine du matériel informatique mais cela s'écarte des compétences de mathématiciens...)

L'état actuel de Giac 

Giac est disponible au téléchargement à partir de ma page web http://www-fourier.ujf-grenoble.fr/~parisse sous forme de code source dans les mêmes conditions que les logiciels du projet GNU (ce qui permet en principe de le compiler sur n'importe quel Unix, y compris Darwin en utilisant le trio configure, make, make install, mais aussi sous Windows avec cygwin), ou sous forme de binaires compilés pour Linux PC (binaires statiques pour processeur compatible "Intel" x86), Linux Familiar (distribution Linux produite par Compaq pour processeur ARM tournant sur des Pocket PC) et Windows (95, NT et au-delà). Il n'existe pas de portage sous Windows CE pour l'instant mais le portage de PARI et maxima sur cet OS laisse penser que cela est possible.

Le répertoire check du répertoire source contient les tests automatisés effectués pour détecter l'introduction accidentelle de bugs, il donne une idée des capacités actuelles de Giac (pour tester les performances de giac, on peut utiliser la commande cas en mode console après avoir défini la variable d'environnement SHOW_TIME).

Actuellement, giac est composé des briques extérieures logicielles suivants (sous licence LGPL ou GPL):

• GMP (entier et flottants en précision arbitraire) nécessaire
• FLTK/FLNX (librairie graphique permettant de faire tourner xcas sur Windows, XWindows pour FLTK ou Microwindows/Nano-X pour FLNX) facultatif
• import de fonctions de PARI (pour l'arithmétique, pour l'instant factorisation d'entier, test de primalité déterministe, recombination de facteurs polynomiaux) facultatif
• import de fonction de GSL (Gnu Scientific Library pour le numérique, pour l'instant fonctions spéciales et airy et intégration numérique d'ODE) facultatif

Du point de vue mathématique: polynômes (dense et creux à une variable, creux à plusieurs variables), PGCD (heuristique, modulaire, sous-résultant), Bézout (note pour Marie-Françoise: j'utilise bien les sous-résultants dans le cas non modulaire!), factorisation (sqff, ddf, Cantor-Zassenhauss, Hensel, manque LLL+knapsack) y compris avec extensions algébriques, dérivation, intégration formelle (méthodes heuristiques), sommes discrètes de fractions rationnelles, équations différentielles numérique (GSL), solveur d'équations de type polynomiale à une variable, développement en série et limités (algorithme mrv), algèbre linéaire (Gauss-Bareiss, valeurs propres, vecteurs propres et cycles de Jordan, formes quadratiques), représentation graphique de fonctions (fonction, paramétrique, polaire) en interaction avec la géométrie plane.

Les principaux manques actuels:

• la documentation
• conformité aux standards: Giac place toutes ses fonctions dans l'espace de nom giac mais il faut que je renomme le type générique de entier en gen et que je rajoute le caractère souligné devant les noms de constantes #define
• interface: éditeur d'équation, éditeur de matrice (si possible avec un minimum de fonctionnalités d'un tableur afin de répondre dans un même logiciel à tous les besoins rencontrés ).
• Impression: il faut pouvoir convertir les graphiques en Postscript encapsulé et également pouvoir exporter au format PNG
• graphique 3-d (voire géométrie dans l'espace): il faut probablement utiliser Open-GL, donc la librairie Mesa. Je pourrais ensuite supprimer toute référence à gnuplot.
• compléter l'interface logicielle avec PARI et GSL. L'interface avec GSL ne pose pas de problèmes, celle avec PARI est plus délicate (en particulier l'inclusion de macros, la gestion de la mémoire et les noms de fonction C non conformes aux standards pour une utilisation par d'autres). L'ensemble des fonctions PARI sera donc regroupé dans un unique fichier .cc qui sera le seul à inclure #include <pari/pari.h>.
• fonctionnalités en calcul formel: intégration (Risch au moins dans le cas d'extensions transcendantes), limites (algorithme mrv cas des fonctions "non tractables" et cas des fonctions spéciales), sommes discrètes (Gosper, Zeilberger, séries entières), factorisation (lll et knapsack, pour l'instant assuré via PARI), systèmes d'équations polynomiales (Grobner: F4), d'inéquations (à commencer par le cas 1-dimensionnel).

Les autres librairies mathématiques interfaçable avec Giac que j'ai examinées:

• GiNaC: en fait j'ai travaillé avec GiNaC en 2000 mais j'ai finalement décidé de créer mes propres types. GiNaC est à mon avis trop rigide par une application trop stricte de l'encapsulation des données et trop orienté programmation objet. De plus il utilise une classe intermédiaire (CLN) pour les scalaires numériques ce qui d'une part ajoute une couche de complexité mais pénalise également au niveau performance. A mon sens il faut écrire des fonctions de conversion GiNaC::ex <-> giac::gen dès que la version 1 de GiNaC sera disponible pour permettre d'appeler les fonctions utiles en physique théorique depuis giac et inversement.
• NTL: comme précédemment j'ai commencé à travailler avec NTL pour la factorisation de polynômes mais j'ai arrêté fin 2000, une des raisons est que NTL est incompatible avec la Standard Template Library (sauf à faire des contorsions très compliquées...)

En ce qui concerne les interfaces: il peut et devrait s'en développer plusieurs (on peut imaginer des interfaces de type langage de script comme xmaxima, de type navigateur, pour KDE/Qt, pour Gnome/GTK, à l'intérieur d'un traitement de texte TeXmacs ou lyx ou ..., etc.). Il faudra imaginer un abstraction des types graphiques manipulés (point, courbes représentatives, etc.) qui puisse s'adapter à différents toolkits graphiques. Il est pour l'instant essentiel d'avoir une interface compatible avec les projets de PDA sous Linux (qui utilisent en particulier la distribution Familiar avec XWindows ou son remplacement Microwindows)

Projet de développement collaboratif 

D'ici la fin de l'année 2001, j'espère pouvoir ouvrir Giac au développement collaboratif en complétant la documentation et en travaillant sur la conformité du code aux standards. Il faudra ensuite ouvrir une base CVS, je pense (bien que le projet soit en C++ et pas en C) qu'on pourrait discuter avec www.savannah.org le site de développement de projets de la FSF.

Ensuite il faut s'interroger sur la suite du projet:

• financement. Le financement public peut se faire par déplacement de masses budgétaires (achat de licence) pour le support et la formation, mais aussi par la reconnaissance scientifique des activités de d'implémentation de logiciels libres. Le financement privé de logiciels libres peut se faire par la vente de services aux constructeurs de hardware ou aux éditeurs de contenus pédagogiques utilisant le logiciel (correction de bogues, support de 2ème niveau, développement à façon). Pour réussir, il faut avoir une stratégie "commerciale" sur l'utilisation du logiciel dans l'enseignement mathématique (voir plus loin)
• coordination: il suffit à mon avis de suivre l'exemple des autres logiciels libres. En particulier il n'y a aucun inconvénient à avoir un développement décentralisé pourvu que des rencontres entre les développeurs (sous forme de journées par exemple) puissent avoir lieu régulièrement. Il me parait toutefois important que les personnes implémentant des algorithmes mathématiques soient à proximité d'une équipe de recherche en calcul formel. Un (enseignant- )chercheur dirige le projet.
• Interface. Le développement d'interfaces intuitives requiert à mon avis soit des contractants extérieurs soit un poste de développeur. Vu la rigidité des grilles salariales de la fonction publique, il est probablement préférable d'utiliser des contractants extérieurs pour être au niveau.
• support technique: une fois la version 1 du logiciel publique, il faut une personne pour cela. Son travail consiste à gérer l'archive CVS, la liste de bugs par version, les listes de discussions (giac-devel, giac-bugs, giac-general,...). Elle gère la réception des bugs, les vérifie, indique à l'envoyeur ceux qui ont été corrigés et effectue une première répartition des bugs par développeur. Si on envisage un financement privé, il faut assurer le support technique de 2ème niveau et les relations vis-à-vis des entreprises utilisant le logiciel ce qui peut nécessiter en fonction du succès un 2ème poste.
• formation. Il faut prévoir la rédaction de documents mais aussi de formation "en présentiel" (IUFM, profs de CGPE).