Reprise du message précédent :

t'as capté ou non ?

euh, jsuis supposé lire l'article ieee là?

 
Bon bien merci à tous... Mais ma ccl est qq peu différente...
En fait je vais changer les types de données, ainsi je vais travailler avec des java.lang.Float... Ayant besoin d'une précision à 4 chiffres, ça me suffit...
En revanche ça me fait bcp de modif' étant donné que tout cela est le ruit de plein de f°....
 
 
Encore merci à tous

mais nan t'as rien capté !!!!!!
 
que ce soit des float ou des doubles c'est pareil !!!!  c'est juste l'affichage des float qui est différent !
 
garde tes doubles, et utilise un DecimalFormat(0.####) pour transformer le décimal en chaine à la place de directement l'écrire sur la sortie standard, et tu auras le comportement que tu veux !

bha il est pas très grand.
 
bon, ce qu'il faut capter c'est que un décimal, contrairement à un entier, ca peut prendre un nombre de valeur infinie sur une plage de valeur donnée.
 
=> pour les integer pas de problème : on a droit au un certain nombre de bit (ex : 16) qui permettent de coder un certain nombre de valeur (2^16 => avec 16 bits tu peut représenter toute sles valeurs entre -2^15 et 2^15)
 
pour les flottant c'est plus dur : on ne peut pas définir une plage de valeur dans laquelle on pourra représenter toutes les valeurs décimale ... Donc comment faire ??? on a droit à x bits (ex : 16) et on doit représenter une infinité de valeur avec ca ... y a pas le choix : la seule chose à faire est de "choisir" quelques valeurs (2^16 valeurs) dans une plage de valeurs et laisser des trous entre => imprecision.
 
comme on est en binaire, les valeurs "choisies" ne sont pas des valeurs exactes en base 10 => c'est pour ca qu'on tombre assez facilement sur ce genre de cas...
 
en fait le codage choisi pour les flottant (décrit dans le lien ieee) fait que plus les valeurs sont petites (proches de 0), plus la précision est grande.
 
compris ?

ouais, merci
 
c nul

bha y a rien de magique en info ... comment tu veux stocker un truc qui peut prendre une infinité de valeur  

ben j'en sais rien, j'ai pas une solution comme ça, mais je trouve ça un peu gros pour un nombre aussi peu précis que 1.15 ou 93 quoi ...

ben je te l'ai dit, c'est parce que c'est de la base 2 ... y a pas bcp de chance que tu tombe sur un décimal de base 10

normal, y en a pas

bah ptet un truc du genre utiliser une partie des bits pour définir la précision, qqchose comme ça

la solution dont tu parles ce serait pas plutot d'utiliser 2 entiers ? (un pour la partie entière et l'autre pour la décimale).
 
ca marche, mais c'est moins efficace ... enfin, ca dépend des besoins que tu as mais globalement c'est moins efficace ...

ouais un truc dans le genre
 
bah je trouve ça abérant les resultats qu'on a sur une multiplication aussi simple quoi
m'enfin bon

on peut pas tout avoir

mais je vois pas pourquoi : tu t'en fous si tu a pas besoin d'une grande précision : t'as juste à arrondir à la précision que tu as choisi et ca roule ! ca revient exactement au même !

 
j'ai l'impression que ce que greg voudrait c'est obtenir le chiffre tout rond qui va bien sans devoir passer par des formats machin bidules. Mais bon c'est clair qu'une telle solution ne prend pas tout les cas en compte

ben sauf que je peux pas necessairement deviner à l'avance ... enfin la moindre des choses serait d'avoir un resultat le plus correct possible...

ben oui
si je multipliais 34,2073072 par 3,2975830 je m'attendrais pas à avoir la réponse précise a 48 décimales...
par contre sur un nombre à 2 décimales

je vois vraiment pas le problème ...
 
qu'est ce que vous croyais qu'il fait le System.our.println() ??

ouais mais les 2 décimale c'est en en base 10  
 
mais les ordinateurs récents marchent en base 2
 
prend le codage donné dans la doc IEEE machin, tu verras que 106.95 ca tombe pas juste en base 2

 
euh je suis d'accord avec toi au cas où tu n'aurais pas compris. J'essaie juste de me mettre du point de vue de greg ...

vais leur apprendre à compter moi à ces incapables

pas évident ca
 
là va maintenant falloir que tu te mettes à insulter le mec qui a découvert l'arithmétique en base 2

Mais le résultat donné par Java est très précis ! Faut pas se faire avoir par la barrière psychologique des 9. Rappel : 999.99? n'est *pas* beaucoup moins cher que 1000?. Dans ton cas abs(106.95 - 106.94999999) = 10^-8 ce qui est effectivement un résultat très précis.
 
Solution : comme tes calculs ont une imprécision à 10 chiffres, tu arrondis à 9 chiffres au moment de l'affichage.

 
Je vois pas ce qui te genes, si tu avais eu 106.9500000001 ca t'aurais moins choqué ?
Que tu travailles en flottant ou en double, tu fait des calculs  a une precision pres, pour laquelle tu ne peut pas t'affranchir. C'est comme ca...
 
Ce qu'il faut que tu comprennes c'est que toutes les machines a calculer du monde marchent comme ca, la difference c'est que le resultat est arrondi a un certain nombre de chiffres apres la virgule, ce qui te donne 106.95000000 et donc 106.95
 
 

mais qu'est ce que sait que ce topic? les double ne sont pas des nombres réels... et sans parler de précision, certains nombres à l'écriture finie en base 10, n'ont pas une écriture finie en base2 (et réciproquement)

bon ... vous arrêtez de tous répéter ce que j'ai déjà dit !    
 

ne prend pas le monde de haut comme ça s'il te plait

c'est

j'ai des relans de meskien incontrolés

Je comprends tres bien le point de vue de Greg .
Imaginez le physiciens,chimiste ou autre qui travaile avec beaucoup de decimal et donc ne doivent pas utiliser d'aproximation.
 
Si ils ne peuvent meme plus faire confiance à un ordinateur pour faire une simple multiplication.
 
Imaginez :
a = 1.15000000000000 apres mesure d'un truc
b = 93.00000000000000 apres autre mesure.
 
et  ils font un truc du style :
si a*b == 106.94999999 alors  
 faire un truc  
sinon
 faire autre chose
 
Ils ne feront pas la bonne operation puisque 1.15*93!=106.94999999 alors que d'apres l'ordinateur  
1.15*93==106.94999999
 

 
Mais bon si ca a marché comme ca jusqu'à maintenant ...

 
Mais non ! Ce genre de problème ne gène absolument pas les physiciens justement. Pourquoi ? Parceque l'on connait explicitement la précision des calculs sur les flottants. D'ailleurs, 106.94999999 est une bonne approximation de 106.95. Ensuite, tout physicien qui se respecte n'osera jamais faire de test d'égalité entre nombres réels.
Citaition réelle :
- Examinateur : (...) La tention V est inferieure à 5 Volts.
- Etudiant après 5 minutes de silence : inferieur strict ?
 
Et pour cet exemple précis, les maths nous montrent que le résultat n'est pas si faux que ça car : 106.95 = 106.94999999999... Les 2 sont des écritures possibles pour représenter le même nombre.

refroidis ton neurone. ben ils ont des outils de calcul formel et l'appromimation ils la prennent bien. en physique, t'as besoin de 40 décimales de Pi pour calculer la taille de l'univers.... on en calculé je sais plus combien de millions.... les doubles c'est 64 bits, c'est déjà pas mal. en C, y a les long double sur 96bits (64bits de mantisses, je sais plus combien d'exposant et quelques bits qui servent à rien)
apres si t'es pas encore content, ben tu as des bibliothèques de précision infinie (mais très lente)
note que l'approximation en calcul informel à du bon, si non, tu t'en sors jamais quand tu manipules des racines et des exponentiels.

rien qu'en Java, dans l'api standard t'as java.math.BigDecimal qui permet de faire des calculs d'une précision que tu choisies

merci pour le neurone pense aussi au tiens apparement il bug
 
t'as pas capte je me doute bien qu'ils(ceux qui ont besoin d'etre super precis) doivent avoir de bon outils qui marchent niquel.
mais bon un programmateur lambda (sans grande connaissant de l'impression des doubles& co)
mets un tel test dans son programme ...
 
Désolé mais 1.15*93 je ne me doutais absolument pas que ca pouvais donner un nombre à 10 chiffres apres la vigule et je pense que pas beaucoup de gens (meme ceux qui ont suivit des cours à la fac) le voient du premier coup donc pas beaucoup de gens aurais l'idée de passer en 96bits & compagnie mais bon.
 
si on ne peut plus faire confiance à un ordi pour une simple multiplication ...
Car vous n'arriverez pas à me faire croire que 106.95 = 106.9499999999
 
 
PS: c'est clair si tu pouvais évité de te prendre pour "bruce tout puissant" et dire des truc du style "vous etes des con vous ne comprennez rien" pour un modo ca le fait pas.

 
 
les BigDecimal en Java, c'est bof: c'est très lent (ce qui est normal), y a pas de surcharge d'opérateur, donc dur à manipuler, et que c'est des instances invariantes (si je me souviens bien), c'est lent aussi.
 
mais ça fonctionne, le truc compliqué, les 36 modes d'arrondis    
 
fluf > je suis "tout puissant"
 
 
et pis va falloir que tu te souviennes que 0,9999... = 1 par définition et que les ingénieurs, ils ont un deuxième neurone pour calculer les marges d'erreurs

Si je peux me permettre,
 
   0.9999... ca tend vers 1, mais ca n'est pas 1. Juste par conscience mathématique. Parce que quand je lis ca:
 
   

 
   Je fais des bonds sur ma chaise
 
Stolenkiss

ou pas    
 

qui a parlé d'ingenieur c'etait juste un example (mal choisit peut etre)  
par definition 0.999...=1 ah bon  
t'es le premier qui me dis ca. En parlant de limite et tout ok sinon non.

pi à la base je   par ce qu'il a fallu 1 page pour qu'un mec dise enfin "hey, les doubles sont une réprésentation imprécise des réels"

0.999999.... est ce qu'on appelle en math une écriture dégénérée du nombre 1.