Re-salut à tous !
Vincent Lefevre a Ãcrit :
Quand on prouve un thÃorÃme concernant une implantation sur ordinateur, il faut tenir compte de l'arithmÃtique utilisÃe.
Certes. Cela dit, nous autres matheux avons tendance à faire nos dÃmonstrations sur des ensembles qui ne sont pas forcÃment trÃs appropriÃs à l'arithmÃtique des flottants.
Tiens, d'ailleurs, à ma connaissance, il n'y a pas eut de vrai dÃveloppement sur les consÃquence de l'arithmÃtique des flottants sur la formulation des espaces de Sobolev. Je serais curieux de voir les consÃquence de la perte des propriÃtÃs algÃbriques à ce niveau, Ãa doit remettre en cause une bonne partie de l'analyse numÃrique...
Ce n'est pas forcÃment un problÃme, notamment lorsqu'on suppose que les entrÃes sont exactes (c'est le cas dans le cadre de l'utilisation d'un tableur) et lorsque l'arithmÃtique est à prÃcision arbitraire.
Il y avait justement eu une discussion à Arinews à propos des corrÃlations en arithmÃtique d'intervalles (ici utilisÃe de maniÃre statique pour faire des preuves). L'un avait donnà l'exemple bien connu x (1 - x) avec 0 <= x <= 1, oà on obtient [0,1] au lieu de [0,1/4] si on ne cherche pas à tenir compte du fait que les deux x ont la mÃme valeur dans le calcul de l'intervalle. Certains pensent ainsi que si on ne traite pas ces cas de maniÃre spÃciale, alors on obtient forcÃment des rÃsultats trÃs mauvais (i.e. intervalles trop gros). Mais c'est faux. Quelqu'un a justement dit qu'il n'avait pas eu besoin de tenir compte des corrÃlations dans ses calculs d'erreur (Ãvidemment, on obtient un rÃsultat plus pessimiste, mais il n'y a pas forcÃment une diffÃrence significative, notamment lorsque les erreurs ne sont pas du mÃme ordre de grandeur, ce qui arrive lors de l'approximation de fonctions par des polynÃmes).
Tu as des rÃfÃrences là dessus ?
Ensuite, je suis intÃressà pour connaÃtre l'erreur sur mon calcul, plutÃt qu'un majorant ou des bornes pessimistes.
MÃme si le majorant est tout à fait acceptable? Par exemple, tu affiches 2 chiffres aprÃs la virgule, et le majorant de l'erreur sur la valeur exacte est de 0,0001.
Bon, lÃ, d'accord. Il faudra que je me renseigne plus sur les intervalles.
Oui, Ãa peut Ãtre une bonne mÃthode pour certains types de problÃmes (pour les tableurs aussi, mais ici pas forcÃment la plus adaptÃe).
En fait, son premier avantage est qu'elle n'est pas trÃs intrusive, ce qui permet de l'appliquer à des codes sans beaucoup de modification, simplement en changeant les types standards par des types stochastiques. Elle est trÃs efficace pour faire du diagnostique de code, afin de le valider, avant de l'utiliser avec une arithmÃtique flottante classique mais en sachant que l'on a Ãvità les opÃrations numÃriquement instable. C'est d'ailleurs le premier objectif de CADNA et je ne crois pas que ce soit l'objectif des intervalles, qui sont plutÃt, ce me semble, utilisÃs dans des codes qui ne reviendrons pas à l'arithmÃtique des flottants.
En fait, je pense que c'est là que viens notre mÃcomprÃhension, à la base : je cherche à valider mon code, tu me propose de le modifier. à l'heure actuelle, je crains tout de mÃme que l'utilisation des intervalles dans le calcul d'un raz de marÃe dans la baie de Nice -- exemple de calcul vÃridique -- ne soit pas totalement raisonnable, quand bien mÃme l'effet de dispersion soit maÃtrisà : c'est dÃjà monstrueusement long, ces calculs ! Bon, cela n'a rien à voir avec un tableur...
Ensuite, des dÃveloppements rÃcents montrent que c'est un bon outils pour trouver les tests ou les pas optimaux -- dans un tel cas les codes utiliserons en permanence l'arithmÃtique stochastique et c'est la raison pour laquelle je dois essayer d'amÃliorer les performances.
Maintenant, les gains de prÃcisions en utilisant l'arithmÃtique stochastique dans des utilisations courantes d'analyse numÃrique sont rÃels et trÃs satisfaisantes. Mais là encore, je n'utiliserais pas cette arithmÃtique pour mon raz de marÃe, simplement pour valider mon code avant de lancer les gros calculs.
Enfin, quand à savoir ce qui est plus adaptà à un tableur, justement, je n'en sais rien.
Je trouve que ce serait intÃressant. Notamment la question suivante: est-ce que si une arithmÃtique exacte avait Ãtà utilisÃe, alors les rÃsultats affichÃs auraient Ãtà diffÃrents (genre une erreur sur le dernier chiffre de certains rÃsultats)? Et est-ce qu'une arithmÃtique plus prÃcise aurait pu permettre d'Ãviter ces erreurs (cadre d'une utilisation classique)?
Formidable !
Par contre, pour suivre la mÃthodologie d'OpenOffice.org, il serait prÃfÃrable d'ouvrir un fil sur dev -- ou plutÃt dev-fr pour ne pas se couper de ce qui à lancà le sujet à l'origine, -- ce qui voudrait dire qu'il faudrait que tu t'y inscrives. à toi de voir.
Cela dit, une premiÃre Ãtape est de savoir ce qu'est une utilisation classique de calc. Or, cette liste propose un bel Ãchantillon d'utilisateurs, je vais donc de ce pas faire un nouveau message demandant qu'elle est l'utilisation que font les utilisateurs de calc.
Ou mÃme le rapport entier? Il sera diffusà sur le web, je suppose, non?
C'est-Ã-dire qu'une bonne partie du rapport porte sur comment optimiser la bibliothÃque BLAS utilisant des types stochastique dans une implÃmentation synchrone, ce qui fait plein de mots compliquÃs et s'Ãloigne pas mal de ce qu'attendent les  utilisateurs lambdas,  qui me semblent surtout intÃressà pour avoir une idÃe des risques qu'ils courent en faisant des calculs sur un tableur.
Quand à la diffusion sur le web, ben... j'espÃre !
à bientÃt.
Yoann LE BARS,
alias Le Farfadet Spatial--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
