On 2005-02-25 12:58:55 +0100, christianwtd wrote: > Je ne pensais pas faire avancer le schmilblic dans cette discussion. De > fait il avance peu. Ce qu'il manque, mais je n'ai peut-�tre pas s� > trouver l'info, c'est surtout des renseignements sur les modes de calculs. > Si on connais le nombre d'octets et les diff�rents modes (entiers, > d�cimales) de calculs, on doit pouvoir d�finir � l'avance le degr� de > pr�cision des calculs. C'est un �l�ment absent, dommage.
J'ai recherch� un peu sur le site d'OpenOffice (recherche sur "rounding"), et je suis tomb� l�-dessus: http://sc.openoffice.org/servlets/ReadMsg?listName=dev&msgNo=1316 qui dit: ------------------------------------------------------------------------ [...] It's a bit different. A result that's almost 1.1 is kept as-is, but when compared to a "real" 1.1, the numbers are treated as equal if they are very close. rtl::math::approxEqual (from sal/inc/rtl/math.hxx) is used for that. It doesn't work when comparing to 0, so additions and subtractions have to be treated the same way (approxAdd, approxSub). These methods are used throughout the function implementations. Niklas ------------------------------------------------------------------------ J'ai regard� dans le source, et effectivement, approxEqual() est utilis�e un peu partout dans "sal/inc/rtl/math.hxx". En gros, deux nombres a et b sont consid�r�s comme �gaux si |a - b| < 2^(-48) |a|. � partir de l�, il y a une fonction d'addition ApproxAdd(a, b) qui renvoie 0 exactement si approxEqual(a, -b) est vrai, etc. Ceci doit expliquer pourquoi avec OpenOffice, 2.73 / 2 donne 1.37 (avec arrondi � 2 d�cimales), alors qu'en C, on obtient 1.36 (car 2.73 converti en binaire donne une valeur un peu inf�rieure, donc la division par 2 donne une valeur un peu inf�rieure � 1.365). Maintenant, si je reprends l'exemple qui avait �t� donn� initialement: A1: 123456,78 B1: =(A1-ENT(A1))*100 C1: =ENT(B1) A1 est converti de mani�re interne en binaire (valeur approch�e � 2^(-53) pr�s environ, car c'est de la double pr�cision IEEE qui est utilis�e). Pour B1, on commence par calculer A1 - ENT(A1). Ces deux nombres sont tr�s proches; on parle de � cancellation �. Le r�sultat est petit par rapport aux nombres de d�part (0,78 vs 123456), et bien que cette soustraction se fasse exactement en base 2, l'erreur relative (en tenant compte de l'erreur de d�part due � la conversion de 123456,78 en base 2) est beaucoup plus grande. B1 a ainsi une valeur tr�s proche de 78, mais � cause de la cancellation, l'erreur relative est sup�rieure � 2^(-48). Dans B1, 78 est affich�, car l'arrondi (au plus pr�s) � 2 d�cimales donne 78,00. Mais pour C1, la fonction approxEqual() utilis�e dans approxFloor() d�tecte que la valeur est diff�rente de 78, car l'erreur relative est sup�rieure � 2^(-48). Donc c'est 77 qui est affich�. Note: ce 2^(-48) est en dur dans le code d'OpenOffice; ce n'est pas configurable. � ce propos, le logiciel Mathematica a une approche diff�rente: il garde la trace d'une estimation de la pr�cision � chaque calcul. Cf http://documents.wolfram.com/mathematica/book/section-3.1.5 Maintenant que ce soit la m�thode d'OpenOffice ou la celle de Mathematica, cela ne r�sout pas tous les probl�mes et les r�sultats ne sont pas du tout garantis. Pour du calcul scientifique, ce n'est pas terrible, car on ne sait pas trop ce qui se passe en interne. -- 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]
