Je suis en train de développer une application et je butte sur le même problème depuis des semaines et après une longue analyse j'ai trouvé la preuve quasi formelles que le problème vient du langage lui-même. Je m'explique : mon application doit afficher en projection des objets en 3D (comme les vue de face, de droite etc... dans des logiciels tels que 3Dstudio maya ou autres). Afin de mieux se repérer il doit afficher une grille de lignes que je triple toute les dix unités. Quand le zoom devient trop grand, je divise chaque case en dix et inversement quand le zoom et trop large la grille n'affiche qu'une ligne toute les dix unités et ne triple que tous les cents etc. Le problème n'est a priori pas insurmontable seulement voilà, lorsque le pas de ma grille (initialement égal à 1) devient plus petit que 1 (il est redéfinit par pas = pas/10.0) ça déconne: lorsque je le multiplie par des entier (plutôt des double "ronds") le résultat n'est pas le bon et j'en viens à des aberrations du genre (0.0 + n*pas)%pas = 0.0 qui me renvois false. Ce truc me rend fou depuis des semaines et j'ai tout tenté pour contourner ce bug en vain... même la fonction arrondi (du tp n°1 je crois) et la fonction Math.floor me donnent le même bug. J'ai résumé le problème dans la fonction que voilà:

double x = 0.0;
double pas = 1.0;
pas = pas/10.0;
while(x%pas == 0.0){
x = x + pas;
System.out.println(x);
}

C'est censé être une boucle infinie et je l'ai testée sur plusieurs PC et vous pouvez vérifier elle s'arrête au bout de trois itérations. Ayant fais un peu d'assembleur au lycée je me doute que ça doit avoir un rapport avec le bit de retenue mais je suis incapable de trouver une solution.
J'espère que quelqu'un pourra m'aider, merci d'avance.

Salut,
je ne pense pas que cela doit etre une boucle infini:

valeur initial:
x=0.0
pas=0.1

tour1
x=x+pas=0.0+0.1=0.1
0.1%0.1=0.0
tour2
x=x+pas=0.1+0.1=0.2
0.2%0.1=0.0
tour3
x=x+pas=0.2+0.1=0.3
0.3%0.1=0.1 != 0.0
source

donc il est logique qu'il quitte la boucle au bout de 3 tours!

Bonne continuation.

il est pourtant facilement démontrable que quelque soit l'entier n et quelque soient les réels x et y on à : (x + n*m) congrus a x modulo m (cela signifie que la division euclidienne de x par m aura le même reste que celle de x+n*m par m) . Une rapide démonstration: l'opération modulo renvoi le reste de la division euclidienne de l'opérande par le modulo. On a donc le reste de (x + n*m)/m (= x/m +n*m/m) soit le reste de x/m car n étant entier n*m/m = n + 0 donc pas de reste. Dans notre cas on à bien 0.3/0.1 = 3 soit un entier et pas de reste. Vous remarquerez que lorsque le pas est de 1.0 la boucle est bien infinie. Le problème est plus gênant que ça: vous pouvez vérifier, au bout de trois itérations on obtient 0.2 + 0.1 = 0.30000000000000004 !!! En tous cas c'est le résultat que j'ai obtenu sur mon PC et sur celui de mon frère. Je pensais que c'était due au bit carry mais je viens de remarquer que même si on assigne directement la valeur 0.1 au pas (au lieu de l'obtenir par division) on en arrive au même résultat aberrant. Je vient même de faire le test et lorsque je demande le résultat de 0.3/0.1 le programme me renvoi 2.9999999999999996 au lieu de 3. Je commence à me demander si j'ai une mauvaise version du JDK ou si JAVA est un langage approximatif mais en tous cas c'est difficile de faire quelque chose avec des calcules aussi faux. Cela m'intéresserait vraiment beaucoup de savoir si tous les PC donnent les même résultats. Je ne suis donc pas convaincu par votre explication mais merci beaucoup pour l'intérêt que vous avez porté à ce sujet. Bonne continuation à vous aussi.

What Every Computer Scientist Should Know About Floating-Point Arithmetic

Bonjour DamnedHippie,

Citation

Je suis en train de développer une application et je butte sur le même problème depuis des semaines et après une longue analyse j'ai trouvé la preuve quasi formelles que le problème vient du langage lui-même

google n'est pas votre ami?
dans les premiers résultats d'une recherche en tapant java+problème+arrondi
humble lien