Version imprimable
bonsoir
voilà je voudrais savoir pourquoi la condition çi-dessous est fausse, regardez :
pourquoi ? est ce que cela est-il dù à l'incertitude, est ce qu'on devra en prendre compte ?Code:
2
3
4
5
6
7
8
merci infiniment d'avance !!!
Bonjour,
Ça marche bien chez moi (gcc 4.4.4 64 bits). En plus, 12,5 est un nombre fini en binaire, « 1100,1 », donc il n'y a pas d'imprécision due au format.
Quel compilateur utilises-tu et sur quelle plateforme ?
Bonjour,
Un meilleur code ne serait il pas:
Code:
2
3
4
5
6
7
8float x=12.5f; x-=12; if(x==0.5f) { }
d'ou vient ce f, je l'ai jamais vu !!8O
quel est mon problème au juste ??
Et si tu fais :
Code:x-=12.0;
Citation:
Envoyé par Obsidian
moi c ----> (gcc, 32 bits) !!
Ce f signifie que le nombre est un float.Citation:
Envoyé par fred_sell
12.5f est un float alors que 12.5 est un double (qui sera converti en float lors de l'affectation).
Bonjour,
J'avoue que moi non plus, je n'avais jamais vu une écriture du genre
float x=12.5f;
Par contre la comparaison (==) de 2 float a généralement peu de chance de marcher. Par principe et par habitude, il faut écrire
J'ai choisi 1.e-5, mais cela dépend de la précision.Code:
2
3
4
On pourrait se dire, autant travailler en int ou en long, par exemple en centimes. C'est souvent une bonne méthode.
S'il s'agit de coordonnées, le programme va probablement faire des opération autres que des additions et des soustractions. Donc il est probable que le même problème se présente aussi, même pour des valeurs entières.
Le test "==" doit être réservé aux cas où on est sûr que le valeurs sont strictement égales.
Cordialement.
Avec ou sans f, le code présenté par le posteur doit donner VRAI comme résultat de la comparaison et Obsidian , plus haut, a bien expliqué pourquoi.
Oui, 12.5 est un nombre fixe, si on fait le test
if (x == 12.5) //on obtiendra VRAI parce que X est EXACTEMENT égal à 12.5.
Maintenant,
x -= 12.0;
if (x == 0.5) //on obtiendra généralement FAUX parce que X est à peu près égal à 0.5.
C'est à dire que dans le cas général où le test de comparaison ne sera pas fait pour savoir si x a été modifié, mais pour comparer la valeur de x à quelque-chose, il faudra faire
Code:
2
3
4
Ah bon? Tu peux m'expliquer en detail pourquoi?Citation:
Envoyé par Pierre Dolez
A mon avis, 12.5, 12 et 0.5 etant exactement representables dans les formats de flottants habituels (... en fait, dans tous les formats flottants ayant reellement ete utilises que je connais, y compris les plus tordus), le calcul sera exact. Il y a eu quelques implementations ne donnant pas toujours un resultat exact dans ce genre de circonstances pour la division, mais je n'ai jamais entendu dire que ce fut jamais le cas pour l'addition ou la soustraction.
Soit, vous avez parfaitement raison avec la soustraction.
Il n'en reste pas moins vrai qu'il ne faut en général pas compter avec une EGALITE entre 2 float.
La plupart du temps, si on travaille en float voire an double, c'est parce qu'il y a de nombreuses décimales.
Je suppose que si fred-sell a posé la question, c'est qu'il a rencontré le problème. Le code qu'il a montré est un exemple théorique. Dans la pratique, on ne fait pas ce type de calcul avec une grosse machine, mais la valeur de x est lue sur un fichier, on fait des opérations sur cette valeur, et pas seulement une soustraction simple etc etc.
Donc si on ne fait pas la comparaison comme je l'ai montré, on est sûr de se planter, mais on n'est pas sûr de le voir tout de suite, c'est pourquoi, il FAUT bannir les comparaisons de float avec "==".
Remarque de langage : quand je dit que x est "à peu près égal à" 0.5, une valeur float étant sur 32 bits, ce qui donne 7 chiffres significatifs, le huitième est forcément faux, mais la valeur avec 6 chiffres significatifs est juste, le 7è étant aléatoire.
Donc un flotant n'est JAMAIS exact, par définition, il y a d'ailleurs bien des cas où si on lit 1.0 sur un fichier et qu'on l'imprime, on risque bien d'avoir 0.9999998.
Si vous dites le contraire vous induisez en erreur beaucoup de jeunes programmeurs.
En général il faut se méfier des affirmations tranchées sur les flottants: elles sont fausses.Citation:
Envoyé par Pierre Dolez
S'il faut de nombreuses décimales, je conseille fortement d'éviter les floats et les doubles risquent d'être limites.Citation:
La plupart du temps, si on travaille en float voire an double, c'est parce qu'il y a de nombreuses décimales.
Si on la fait comme tu l'as montré, on est tout aussi sûr de se planter. Il faudrait au strict minimum indiquer pourquoi tu as choisi 1E-5. Dans le cas présent c'est un nombre tombé d'on ne sait où. Il va être ajusté au petit bonheur la chance pour faire passer quelques exemples sans qu'on ait la moindre indication de pourquoi c'est la bonne valeur -- enfin... dans le cas improbable où c'est une valeur sensée.Citation:
Donc si on ne fait pas la comparaison comme je l'ai montré, on est sûr de se planter,
Si tu penses cela, je te défends d'enlever les égalités de flottants quand j'en écris. Pour commencer, si j'ai besoin du fait que ma relation d'égalité doit être une relation d'équivalence, je fais quoi?Citation:
il FAUT bannir les comparaisons de float avec "==".
On n'est d'accord sur a peu près rien. Pour les float sur 32 bits au format IEEE, le parcours format decimal-float-format decimal est garanti sans perte jusqu'à 6 chiffres décimaux. Mais ça ne veut certainement pas dire qu'une représentation décimale avec plus de chiffres a des chiffres "faux" ou "aléatoire", du moins si elle est bien faite.Citation:
Remarque de langage : quand je dit que x est "à peu près égal à" 0.5, une valeur float étant sur 32 bits, ce qui donne 7 chiffres significatifs, le huitième est forcément faux, mais la valeur avec 6 chiffres significatifs est juste, le 7è étant aléatoire.
<coup de gueule hint="t'est pas visé personnellement">Citation:
Donc un flotant n'est JAMAIS exact, par définition, il y a d'ailleurs bien des cas où si on lit 1.0 sur un fichier et qu'on l'imprime, on risque bien d'avoir 0.9999998.
Si vous dites le contraire vous induisez en erreur beaucoup de jeunes programmeurs.
Les calculs sur les flottants peuvent être exacts. C'est en disant le contraire qu'on induit en erreur les jeunes programmeurs.
La première chose à comprendre, c'est que les flottants ne sont pas des réels et ne se comportent pas comme eux.
Et j'en ai marre de ceux qui ayant compris cela s'arrêtent et ne vont pas plus loin, pensent les flottants sont des choses bizarres incompréhensibles où les erreurs apparaissent aléatoirement et qui ne peuvent être maîtrisées que par des techniques de programmation superstitieuses.
Donc la deuxième chose à comprendre, c'est que des trucs simples ne suffisent pas à permettre de manipuler les flottants sans problèmes. Dire qu'il ne faut jamais utiliser l'égalité mais une comparaison d'intervalle sans indiquer comment calculer l'intervalle (*), sans indiquer que le résultat n'est pas une relation d'équivalence (propriété que la plupart des gens suppose quand on leur donne une relation sensée remplacer l'égalité) c'est pas rendre service. Le penser, c'est s'illusionner.
La troisième chose à comprendre, c'est que l'arithmétique sur les flottants si elle n'obéit pas aux même règles que l'arithmétique sur les réels obéit quand même à des règles déterministes. On peut les maîtriser. On peut borner la différence entre le résultat obtenu en utilisant les flottants et celui qu'on aurait obtenu avec les réels. On peut améliorer ces bornes en faisant attention et en utilisant des techniques qui peuvent sembler bizarres ou inutiles (mais qui elles ne tiennent pas de la superstition).
(*) Ou pire comme je l'ai déjà vu en proposant des manières de calculer l'intervalle qui n'ont absolument aucun sens, retournant toujours vrai dès que les deux nombres sont trop petits, retournant toujours faux dès qu'ils sont trop grands.
</coup de gueule>
Je plussoie comme c'est pas permis. C'est pourquoi je déteste les langages qui utilisent des flottants et les appellent "real".Citation:
Envoyé par Jean-Marc.Bourguet
Oui, mais je pense que ça intéresserait la communauté et moi en particulier de connaitre la nuance, et surtout les implication en matière de logique et de programmation.
Merci pour les lins, je vais lire tout ça.
J'en ai un autre en rapport direct avec ce sujet :
http://c.developpez.com/faq/index.ph...AT_comparaison
PS celui-là est écrit en français.
Pour les 3 autres liens, certainement parfait pour la théorie, mais j'avoue que je n'ai fait qu'un survol très rapide.
Wow, ce document jette la honte sur Melem. Il n'y a pas de réels en C.
Par contre, la suite est intéressante, avec le calcul d'un epsilon approprié... :ccool:
Oui mais dans la pratique : QUE DOIT-ON FAIRE ou NE PAS FAIRE.
Je pense que c'est ça qui intéresse les développeurs en C.
Un ou deux exemple s'il vous plait.
Citation:
Envoyé par Pierre Dolez
Il y a quand meme vraisemblablement moyen d'ecrire quelque chose de plus simple que ce qu'il y a dans les liens que j'ai donne, mais je ne connais pas de documents de cette sorte (j'ai un peu cherche pas pas trop). J'ai un vague projet d'un ecrire un, mais meme si j'en trouve le temps (ce n'est jamais qu'en position 3 ou 4 sur ma liste de choses a faire de ce genre) ca sera quand meme trop long et trop mathematique pour ceux qui cherchent des recettes simples a appliquer sans reflechir.Citation:
Envoyé par Jean-Marc.Bourguet