On 2005-03-02 23:20:33 +0100, Le Farfadet Spatial wrote: > En fait, l'arithm�tique des intervalles doit �tre consid�r�e comme > un nouvel environnement pour le calcul scientifique, ind�pendant de > l'arithm�tique a virgule flottante. Cette m�thode ne tient pas > compte de la compensation des erreurs d'arrondi et provoque un effet > de dispersion.
C'est vrai si on parle d'erreurs importantes. Ici, le but est d'avoir des intervalles � chaque fois tout petits. L'arithm�tique d'intervalles ici n'est rien de plus qu'une analyse d'erreur dynamique. Si tu n'es pas convaincu, tu peux t'amuser avec iRRAM et voir qu'en pratique, dans la plupart des cas, �a fonctionne bien. Dans les autres cas, le r�sultat obtenu avec une arithm�tique classique sera de toute fa�on probablement faux. > En gros, � chaque calcul, en admettant que l'on a recourt qu'� des > op�rations stables, ce qui exclue l'addition de deux valeurs de signes > oppos�s avec les probl�mes de cancellation que cela entra�ne et toutes Non, l'addition de deux valeurs de signes oppos�s (ou la soustraction de deux valeurs de m�me signe) n'est pas du tout exclue. En cas de cancellation, il faut de toute fa�on augmenter la pr�cision pour avoir un r�sultat acceptable. > sortes de fonctions math�matiques, donc finalement qu'� des additions de > nombres de m�me signes et des multiplication, l'�cart est de l'ordre du > dernier chiffre significatif exacte. Admettons que nous utilisions la > double pr�cision et qu'au d�part les donn�es sont enti�rement > significatives (on peu r�ver), c'est-�-dire que l'on a 53 bits (52 bits > de mantisse plus le bit cach�) significatifs exactes. Apr�s une > op�ration du type de celles d�finies en d�but de paragraphe, on n'a plus > que 51 bits significatifs exactes, apr�s 10 op�rations, 42 et ainsi de > suite. [...] C'est n'importe quoi. Dans le cas d'op�rations "r�guli�res", on perd en gros un ulp � chaque op�ration, donc n ulp au bout de n op�rations. Bref, le nombre de bits perdus est en log du nombre d'op�rations. Si on perdait un bit � chaque fois comme tu dis, la double pr�cision ne servirait � rien dans les calculs scientifiques, o� il y a beaucoup plus qu'une cinquantaine d'op�rations. > En plus, aller donner � un financier un r�sultat sous cette forme : > [12 487,475 ; 12 487,579 47], je crains que cela ne soit pas > satisfaisant. On peut renvoyer le r�sultat sous une autre forme si n�cessaire. > Conclusion : si l'on est pas avertit, il ne vaut mieux pas utiliser > les intervalles, sous peine de se retrouver avec des r�sultats qui ne > signifient rien. Mieux vaut avertir un minimum. Tu pr�f�res que les utilisateurs se retrouvent avec des r�sultats faux et/ou qu'ils ne comprennent pas? > Sachant qu'en plus cette arithm�tique gr�ve les performances (comme > toutes les arithm�tiques qui ne sont pas directement support� par le > mat�riel) je pense qu'il n'est pas judicieux d'int�grer cette > arithm�tique dans un tableur. Dans le cadre d'un tableur, pas de probl�me de performance en g�n�ral. Tu es hors sujet. Tu peux aussi noter qu'il existe une option qui demande au tableur de passer son temps � faire des conversions base 10 / base 2 (cf d�but de l'enfilade), et pourtant �a ne semble g�ner personne. -- Vincent Lef�vre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / SPACES project at LORIA --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
