Rédu tion de problèmes algébriques et omplexité

Il existe deux façons de réduire un problème d'élimination algébrique en un problème

d'élimination diérentielle. La première façon onsiste à regarder les indéterminées du

sys-tèmepolynomialàsimplier ommedesfon tions onstantes pluttque ommedesnombres

et àregarder les équationspolynomiales ommedes équationsdiérentielles d'ordrezéro.

L'appli ation d'un algorithme de dé omposition en haînes diérentielles régulières sur

un telsystème produit lesmêmes haînesque ellesque pourraitproduire un algorithmede

dé omposition en haînes régulières non diérentiel.

Lase ondefaçon onsisteà oderlesystèmepolynomialinitialenunsystèmeauxdérivées

partielles linéaires,en une indéterminéediérentielle et à oe ients onstants. On illustre

le odagesur un exemple : lesystème

S1

suivant de

Q[x, y, z]

x²y + 3 z− 1 = 0, 7 x + y z − 2 = 0

se ode en le système aux dérivées partielles linéaire

S2

suivant de

R = Q{u}

muni des dérivations

δx, δy, δz

uxxy+ 3 uz− u = 0, 7 ux+ uyz− 2 u = 0.

Que se passetil si on al ule une base de Gröbner réduite

G₁

de l'idéal engendré par

S₁

dans

Q[x, y, z]

pour un ordre admissible quel onque et si on applique le même pro édé de odage sur les polynmes de

G1

? On obtient une haîne diérentielle régulière

C1

omplè-tement réduite pour le lassement sur

Θ{u}

induit par l'ordre admissible. Cette haîne est égale à elle qu'on aurait obtenue en appliquant RosenfeldGröbner sur

S2

(on remarque que RosenfeldGröbner ne produit au uns indage sion l'applique àun système diérentiel

linéaire)or Ernst Wilhelm Mayr etKlaus Kühnle ont montré [57℄ lethéorème suivant [104,

Theorem 21.40℄.

Théorème 13 Le problème du al ul d'une base de Gröbner réduiteest expspa e omplet.

On en déduit la proposition suivante qui donne une idée de la omplexité du résultat

de l'algorithme RosenfeldGröbner et non de l'algorithme luimême, qui est né essairement

pire.

Proposition 44 Le problème du al ul d'une haîne diérentielle régulière omplètement

réduite est expspa edur.

Comme le font remarquer Joa him von zur Gathen et Jürgen Gerhard, le résultat de

Mayr etKühnleest obtenuen onsidérantdes systèmesde natureplus ombinatoireque

géométrique etonest en droitd'espérer quelesproblèmes diérentielsnaturelssont

Con eption des bibliothèques BLAD

 Comme souventà estade,la réussitede l'idée dépendaumoinsautant

de l'énergie onsa rée àsaréalisation quede sesqualités initiales.

Anonyme

La on eption des bibliothèques BLAD remonte à peu près à 2000. J'ai réalisé deux

versions en C++ puis deux versions en langage C. La se onde version en C orrespond à

la version a tuelle. Elle fait approximativement quarante mille lignes de ode, e qui est

peu, omparativement aux quatre vingt mille de la Gnu Multiple Pre ision Library ou des

deux ent millede la Gnu S ienti Library. J'ai développé les bibliothèques sur plusieurs

ar hite tures en parti ulier sur des ma hinesdisposantde pro esseurs INTEL, fon tionnant

sous LINUXet sur une station SUN BLADE 100, disposant d'un pro esseur SPARC de 64

bits, fon tionnantsous SOLARIS9.

10.1 Premiers hoix

10.1.1 Éviter d'é rire un système de al ul formel

J'ai voulu éviter de me perdre dans la tentative d'é riture d'un système de al ul

for-mel, qui est une tâ he impossible pour une personne seule. Je suis don parti d'un projet

d'appli ation utilisant l'élimination diérentielle ( elui dé rit dans le hapitre 4) et je n'ai

développéà peu de hoses près queles outils né essaires àsa réalisation.

J'ai été fortement impressionné par la on eption de la Gnu Multiple Pre ision Library

de Torbjörn Granlund.J'aiessayéde réaliserun analoguede ette bibliothèque (quine gère

 que lesgrands nombres) pour les systèmes de polynmes diérentiels.

10.1.2 Le hoix de la li en e

J'ailongtempshésitéentrelaGeneralPubli Li ense(GPLenabrégé)etlaLesserGeneral

Publi Li ense (LGPL en abrégé). J'ai nalement hoisi la se onde quiest moins oer itive.

En d'autres termes, seul un programme sous GPL peut utiliser une bibliothèque sous GPL

alors que tout programme (même un programme non  open sour e ) peut utiliser une

bibliothèque sous LGPL. LaGnu Multiple Pre ision Library est protégée par la LGPL.Elle

estutiliséeparlelogi ielMAPLEquin'estpas opensour e.LaGnuS ienti Libraryest

protégée par la GPL. Nos logi ielsdéveloppés dans le adre du projet LÉPISMEl'utilisent.

Nous sommes don obligés de les protéger par la GPL. Je ren ontre déjà des di ultés

à populariser les méthodes d'élimination diérentielles. Je n'ai pas voulu en ajouter une

supplémentaire en adoptant une li en etrop ontraignante.

10.1.3 Le hoix du langage

J'aibeau ouphésitésurlelangage.Jevoulaisimpérativementunlangageassezlargement

répandu. Je her hais aussi un langagequimepermetted'é rireune bibliothèque quipuisse

être appelée depuis un programme prin ipal é rit en C ou en FORTRAN. Voi i quelques

langagesauxquels j'aipensé :

ALDOR Unproblèmede diusion.Ce langagesemblaitpourtanttoutàfaitadaptéàmon

projet.Maisiln'existaitqu'une entainededéveloppeursALDORaumondeetun seul

ompilateur,maintenupar une seule équipeuniversitaire.

CAML J'ai raint aussi un problème de diusion.

JAVA Un bon andidat, utilisé par ILOG pour la réalisationde ses solveurs il me semble.

Mais,s'iln'estpas tropdi iled'utiliserune bibliothèqueCàpartird'uneappli ation

prin ipale é rite en JAVA, l'inverse paraît plus di ile.

J'ai ommen é par tenter des réalisations en C++. J'ai ren ontré deux di ultés. La

pre-mière était liée aux ompilateurs : des programmes C++ qui me semblaient pourtant

res-pe ter lanormeANSI étaienta eptés par ertains ompilateursmais pas par d'autres. Des

optimiseurs de ode avaient des omportement erratiques : des instru tions de lan ement

d'ex eptions (throw) n'avaient plus au un eet lorsqu'on optimisait le ode. Il y avait des

erreurs dans lemé anisme d'instan iationdes templates: le ompilateur oubliaitde générer

le ode orrespondantà ertaines fon tions, equiprovoquaituneerreuràl'éditiondesliens.

La deuxième di ulté était davantage une dé eption. Le langage C++ fournit des

mé- anismesen apparen e très séduisantspour laréalisationde bibliothèques de al ulformel:

héritage, généri ité, possibilité de redénir les opérateurs arithmétiques pour améliorer la

lisibilité du ode, possibilité de redénir l'ae tationet le onstru teur de re opie pour

im-planter un  garbage olle tor  automatique. Ces mé anismes sesont avérés inadaptés.

Une première idée onsiste à her her une solution fondée sur le mé anisme d'héritage.

Onaboutitassezviteàdeshéritages multiples,oùlesstru turesalgébriques(lesanneauxde

polynmes par exemple)sont implantées par des lasseset oùlesélémentsde es stru tures

(les polynmes) sont implantés par d'autres lasses qui ontiennent une référen e vers la

stru ture à laquelle ils sont mathématiquement ensés appartenir. Le résultat est une

deux exemples.

Pourimplanterlespolynmesenune indéterminée,onest onduitàdistinguer euxpour

lesquelsondispose d'unalgorithmededivisioneu lidiennedesautres.Unesolutionnaturelle

onsisteàdé larerune lasse

A

pour lespolynmesgénérauxetune lasse

B

quihéritede

A

pour les polynmesqui disposent d'une division eu lidienne.Ce type d'héritageoù la lasse

B

qui hérite ajoute des fon tionnalités mais pas de  hamps  ( 'estàdire des zones de sto kage de données) à la lasse

A

dont elle hérite est très fréquent en al ul formel. C'est même le seul type d'héritage dont on ait vraiment besoin dans e domaine. Mais omme

le mé anisme d'héritage C++ est onçu pour gérer le as général, on est obligé d'é rire un

nombrenon négligeablede lignes de ode pour expliquerque lesinstan es de

B

doivent être gérées (ae tation, onstru teur de re opie qui ne sont pas hérités)exa tement de lamême

façon quelesinstan es de

A

.Tout e odesans intérêtsur lefonddiluele ode desfon tions oùil sepasse réellement quelque hose. Dansle as de deux lasses, e n'est pas très gênant

mais onpeut viteaboutirpour lesseuls polynmes en une indéterminéeàquelques dizaines

de lasses.

Même l'anneau

Z

des entiers n'est pas simple : pour les appli ations en algèbre dié-rentielle, il faut le on evoir dès le début omme un anneau diérentiel, e qui n'est pas

vraimentnaturel.

Lesystèmede al ulformelAXIOMillustreparfaitementlalourdeuràlaquelleonaboutit

lorsqu'onpousse ettelogiqueaubout.EtAXIOMs'appuiesurunlangagedeprogrammation

spé ialement onçupourgérer e genrede di ultés (langagedontALDOR est issu), e qui

n'est pas le as de C++.

L'idée qui vient ensuite onsiste à utiliser le mé anisme des templates pour implanter

du ode générique. On aboutit à une solution plus naturelle ave un ode plus rapide. Un

gros avantage vient du fait qu'on n'est pas obligé de oder les fon tions qu'on n'utilise pas.

Un gros in onvénient : le ode qu'on é rit n'est pas ompilé tant qu'il n'est pas appelé, e

qui fait qu'on peut être amené à orriger des erreurs de syntaxe dans des fon tions qu'on

a é rites plusieurs mois auparavant mais qu'on n'a jamais eu l'o asion de ompiler. Ces

di ultés sont gérables pour du ode simple (des listes génériques par exemple)mais, pour

lespolynmesen plusieursindéterminées,onaboutitàquelquesdizainesdemilliersdelignes

de templates très pénibles à manipuler.

Lapossibilitéderedénirlesopérateursarithmétiquesestassezpeuutile.D'abord,quand

les algorithmes ommen ent à se sophistiquer, es opérations se diluent fortement dans le

ode. Ensuite, pour pouvoir vraiment manipuler les polynmes omme on manipule des

double (des instru tions telles que  return (a + b)*  ave

a, b, c

polynmes) il faut implanterdes mé anismesde garbage olle torassez oûteux.J'avaisimplantéunmé anisme

àbasede ompteursde référen esquiétaientin rémentésetdé rémentés parl'ae tation,le

onstru teur de re opieetle destru teur. Par onséquent, haque fois qu'un polynme était

passé en paramètre à une fon tion, son ompteur de référen e était in rémenté au moment

del'appeletdé rémentéàlan.J'ainipartrouverque 'était her payerleluxedepouvoir

forçantàn'exploiterqu'un sousensembleassezréduitdes mé anismesoerts parlelangage.

Lorsqu'on développe une bibliothèque sur plusieursannées, ilest humainement très di ile

de s'astreindre à une telle dis ipline.Tant qu'à faire,autant programmeren C.

Jene suis pas lepremieràraisonner ainsi.JeanCharlesFaugèreetFabri eRouillieront

euxaussi (avant moi) ommen é à implanter en C++ leur haîne logi ielle GB+RS puis

sont revenus aulangageC pour des raisonstrès similaires.

Dans le document Réécriture algébrique dans les systèmes d'équations différentielles<br />polynomiales en vue d'applications dans les Sciences du Vivant (Page 152-158)