Bonjour,
J ai un petit probleme tout con, si je fait
(x * 3) me donne le resultat 23.400002 et non 23.4 ...Code:
1
2 float x = (float) 7.8;
Voila je sens que la reponse est toute simple, mais je vois pas comment faire arriver a 23.4 :roll:
Version imprimable
Bonjour,
J ai un petit probleme tout con, si je fait
(x * 3) me donne le resultat 23.400002 et non 23.4 ...Code:
1
2 float x = (float) 7.8;
Voila je sens que la reponse est toute simple, mais je vois pas comment faire arriver a 23.4 :roll:
utilise la classe BigDecimal
cf. http://java.sun.com/j2se/1.4.2/docs/api/java/math/BigDecimal.htmlCode:
1
2
3 BigDecimal b = new BigDecimal(7.8); BigDecimal b2 = b.multiply(new BigDecimal(3));
;)
le 3 tout seul est un double pour java par défaut donc crée une autre variable :
Code:
1
2
3 float f1=78.0E-1F; float f2=3.0F;
Ce n'est pas un probleme inherent a Java mais a la maniere dont les ordinateurs stockent les nombres a virgule flottante. C'est pour ca qu'il faut eviter de faire des tests du genre x == 46.2 ou x est un float ou un double. Si tu veux une precision parfaite, utilise BigDecimal comme l'a dit Pill_S. Dans tous les cas renseigne toi sur la maniere dont sont traites les nombres dans la memoire des ordinateurs. Tu comprendras pourquoi par exemple 65536 * 65536 en Java donne 0 ou encore pourquoi 641 * 6700417 donne 1.
faux, le 3 tout seul est converti en float, non pas en double.
si on avait 3.0 alors oui ça serait un double.
Et ça ne change de toute façon rien au problème de l'arrondi.
Il faut soit arrondir à l'aide de la classe Math, soit utiliser la classe BigDecimal.
En tout cas, je conseille toujours de ne pas utiliser les floats ni les doubles pour faire des calculs, on se retrouve toujours avec des erreurs. A mois de faire super attention... Mais pourquoi s'embêter à faire attention quand on peut faire plus simple ?
Ou alors quand on peut tout betement ignorer les erreurs d'arrondi. A moins de realiser une application financiere ou scientifique on peut accepter ces erreurs sans aucun probleme.
Hello.
Et encore, la seule façon 100% correcte d'initialiser à coup sûr un BigDecimal est de le faire avec un String. Par exemple, "2.0" au lieu de 2.0f.
L'initialiser avec un nombre peut tout aussi bien se terminer par une erreur d'arrondi :roll:
2 trois précision pour me "corriger"
Oui en fait tu as raison je pense, 3 tout seul n'est pas un double... c'est un int ici mais comme IN est inclu dans IR on fait une conversion implicite int->float (le cour java sun dit : long l=6; //6 est de type int). donc x*3 avec x float te fait une conversion implicite de l'entier 3 en float puisque x est un float, si je comprends bien.Citation:
faux, le 3 tout seul est converti en float, non pas en double.
par contre :
float f=3.0; est illégal car 3.0 est double effectivement (tiré d'un cour java), il faut écrire "3.0F".
Moi aussi ça fait plusieurs fois que je me prends la tête sur ces float et double :evil: , je viens de faire un petit test qui donne une valeur ""juste"" :
Code:
1
2
3
4
5
6
7
8
9 public class Calcul { public static void main (String args[]) { double d1=7.8; double d2=3; System.out.println(d1*d2); } }
N'oublions pas la solution la plus simple. Utiliser des doubles plutôt que des floats est suffisant pour la plupart des applications. Si on a besoin d'une précision absolue, il faut utiliser BigDecimal, ailleurs c'est un peu utiliser une bombe atomique pour écraser une puce.
Par scientifique, tu veux dire mathématique. Car en science ou en ingénieurie, il faut toujours prendre en compte la précision des instruments de mesure. Donc, ce n'est pas des problèmes d'arrondi de moins de 0.1 pour mille d'erreur qui vont donner dul fil à tordre. :wink:Citation:
Envoyé par Gfx
Mais il faut avoir conscience du problème. :wink:
Je dirai même qu'il faut arrondir après CHAQUE opération. Parce qu'une petite erreur trimbalée dans 50 opérations à la suite qui elles même refont des erreurs, ça peut vite devenir catastrophique...