class test
{
public static void main(String args[])
{
double A = 84.4;
double B = 53.2;
double C = A + B;
C = C - 137.0;
System.out.println("Tot="+C);
}
}ben-iMac:~/Desktop ben$ java test
Tot=0.6000000000000227
), il y a forcément une erreur d'arrondi. Du fait de représentation en base 2, il n'y a donc aucune raison qu'un arrondi se fasse dans ce cas-ci, qui est bien le cas.class test
{
public static void main(String args[])
{
double A = new Double("256.16");
double B = new Double("16.4");
double C = (double)A + (double)B;
System.out.println(A +" + "+ B +" = "+C);
}
}Philou1789 a dit:
des réels en "extended" qui me permettaient de faire des approximations polynômiales de degré 12 ou 14 plutôt que 8 ou 10, ce qui suffisait dans le cas qui m'intéressait. S'il avait fallu aller au-delà, vu qu'il n'y avait pas (au moins de façon simple) de représentations adéquates, il aurait fallu changer d'algorithmes, passer par des procédures itératives plus lentes mais où ces problèmes se posent moins. C'est entre autres pour cette raison qu'ont été développés des tas d'algorithmes numériques de type itératif moins sensibles à ces problèmes.Luc G a dit:d'adapter ses besoins et les possibilités de l'informatique.
Il y a quelques cas dans la vie courante où on a besoins de plus de 6 chiffres significatifs, pas beaucoup où on a besoin de plus de 12 (c'est à dire de mieux que des doubles). Ensuite, c'est souvent un simple problème d'affichage : si tu affiches ton "137" avec 3 décimales, il n'y a plus d'erreur visible, si tu forces l'arrondi à la troisième décimale, tu vas même un peu plus loin que le visible.
Dans les cas où les 12 chiffres ne suffisent pas, soit il faut utiliser des représentation encore plus fines (genre des réels sur 12 ou 16 octets), soit il faut choisir des algorithmes où ces erreurs d'arrondi posent peu de problèmes.
Par exemple, quand il s'agit de résoudre des systèmes d'équations, donc couramment d'inverser des matrices, certaines méthodes (genre pivot) bloquent dès qu'on augmente la taille de la matrice (je me souviens avoir utilisé sous mac os 6
Ce qui est assez "amusant", c'est que les problèmes de précision peuvent être vicieux, les bougres. Exemple typique (celui qui d'ailleurs pose problème pour l'inversion de matrices) quand tu dois manipuler des nombres très différents entre eux, exemple tu soustrais 1.0 de 1.0 e15, forcément, ta soustraction ne fait rien même si tes deux nombres ont l'air très simple : 1 dans les 2 cas mais avec une échelle complètement différente. Il faut donc se débrouiller pour éviter d'avoir des calculs de ce type.
et Luc G, réveilles-toi !
BeNBiBiFoKe a dit:Et merde....il est partit en suçette !
Dès qu'on parle d'arrondi, d'approximation et de toute cette sorte de choses, je me laisse aller, j'ai un brin baigné là-dedans et je rencontre encore dans mon boulot (bien que j'ai laissé les maths de côté il y a un certain temps) les problèmes vicieux dont je cause. C'est du vécu ! 
Luc G a dit:d'adapter ses besoins et les possibilités de l'informatique.
Il y a quelques cas dans la vie courante où on a besoins de plus de 6 chiffres significatifs, pas beaucoup où on a besoin de plus de 12 (c'est à dire de mieux que des doubles). Ensuite, c'est souvent un simple problème d'affichage : si tu affiches ton "137" avec 3 décimales, il n'y a plus d'erreur visible, si tu forces l'arrondi à la troisième décimale, tu vas même un peu plus loin que le visible.
Dans les cas où les 12 chiffres ne suffisent pas, soit il faut utiliser des représentation encore plus fines (genre des réels sur 12 ou 16 octets), soit il faut choisir des algorithmes où ces erreurs d'arrondi posent peu de problèmes.
Par exemple, quand il s'agit de résoudre des systèmes d'équations, donc couramment d'inverser des matrices, certaines méthodes (genre pivot) bloquent dès qu'on augmente la taille de la matrice (je me souviens avoir utilisé sous mac os 6
Ce qui est assez "amusant", c'est que les problèmes de précision peuvent être vicieux, les bougres. Exemple typique (celui qui d'ailleurs pose problème pour l'inversion de matrices) quand tu dois manipuler des nombres très différents entre eux, exemple tu soustrais 1.0 de 1.0 e15, forcément, ta soustraction ne fait rien même si tes deux nombres ont l'air très simple : 1 dans les 2 cas mais avec une échelle complètement différente. Il faut donc se débrouiller pour éviter d'avoir des calculs de ce type.
/michel simon accent / en 1923 j'avais déjà n**q*é ce p****n de floating-point t'es pas sortie avec ça y'en a bien qui joue au sodoku mon c**l (c)tatouille
example darwin-dev-list
/*************************************************************/
#include <stdio.h>
#include <fenv.h>
int main(void)
{
int save_rnd, rnd;
double x, y, z;
save_rnd = fegetround();
if (save_rnd == FE_TONEAREST)
printf("rounding direction is FE_TONEAREST\n");
else
printf("unexpected rounding direction\n");
x = 1.79e308;
y = 2.2e-308;
z = x / y; /* overflow */
printf("%g / %g = %g\n", x, y, z);
x = -1.79e308;
y = 2.2e-308;
z = x / y; /* negative overflow */
printf("%g / %g = %g\n", x, y, z);
fesetround(FE_TOWARDZERO);
rnd = fegetround();
if (rnd == FE_TOWARDZERO)
printf("rounding direction is FE_TOWARDZERO\n");
else
printf("unexpected rounding direction\n");
x = 1.79e308;
y = 2.2e-308;
z = x / y; /* overflow */
printf("%g / %g = %g\n", x, y, z);
fesetround(FE_UPWARD);
rnd = fegetround();
if (rnd == FE_UPWARD)
printf("rounding direction is FE_UPWARD\n");
else
printf("unexpected rounding direction\n");
/* continued */
/*************************************************************/
/*************************************************************/
x = -1.79e308;
y = 2.2e-308;
z = x / y; /* negative overflow */
printf("%g / %g = %g\n", x, y, z);
/* return to round-to-nearest */
fesetround(save_rnd);
rnd = fegetround();
if (rnd == FE_TONEAREST)
printf("rounding direction is FE_TONEAREST\n");
else
printf("unexpected rounding direction\n");
}
/*************************************************************/
tatouille a dit:
). Rermarque, ça ne m'étonnerait pas qu'il y ait une bibli java pour faire ça mais comme je suis déconnecté de tout ça depuis longtemps...
oui y a un truc pour aider sisi c'est dans la doc 
) est tolérable, soit t'es dans le caca.
tatouille a dit:J'AI JAMAIS VU CA !!!!
j'espère que tu n'es pas developpeur ?
molgow a dit:
Luc G a dit:Le problème de départ, c'est d'abord de savoir quelle est la précision nécessaire
..ement parlant(si on veut travailler "propre" il faut de la précision arbitraire) mais en pratique, il y a peu de situations où en même temps :
- ce soit gênant
- ce ne soit pas contournable en ajustant les algorithmes.
avec les impots je verifie au milliardieme de centime d'euro 
