Discussion :

[adilou1981]

Bonjour,

Mon problème est que avec c++ la somme des probas est diferente de 1.

voici des exemples :

0 , 0 , 0 , la somme est0 ,

//c'est la ou ca louche il me donne une somme 1 alors qu il afiche d autres nombres au lieu de 0.
1 , 7.9245e-008 , 3.36624e-007 , la somme est1 ,

0.333333 , 0.333333 , 0.333333 , la somme est1 ,
0.333333 , 0.333333 , 0.333333 , la somme est1 ,
0.790927 , 0.201588 , 0.00748495 , la somme est1 ,
0.333333 , 0.333333 , 0.333333 , la somme est1 ,
0.333333 , 0.333333 , 0.333333 , la somme est1 ,
0.333333 , 0.333333 , 0.333333 , la somme est1 ,
0.333333 , 0.333333 , 0.333333 , la somme est1 ,
0.333333 , 0.333333 , 0.333333 , la somme est1 ,
0.333333 , 0.333333 , 0.333333 , la somme est1 ,
0.333333 , 0.333333 , 0.333333 , la somme est1 ,
0.333333 , 0.333333 , 0.333333 , la somme est1 ,


Quand j ai cherché sur les forums , j ai trouvé que c est un pb de precision du calcul avce les flottant , que j utilise float ou double la somme n est pas tjr precise. cad si j ai 0,33333333+0,33333333, il afiche 0,66666667 . si on fais 1-0,1 10 fois successive on ne tombe pas sur 0 comme prévu mais sur qqc de proche.

il me faut une partie de code pr corriger mes resultats de facon a prendre en considération cette imprecision due au calcul des flottant.

j espere que j ai bien decrit le pb. ca na pas de rapport avec mon code mais avec les possibilités du langage et de l ordinateur. je sai vraiement pas cmt faire

Merci d'avance

[Nogane]

Bonjour,
Je pense que tu devrai forcer le formatage de tes nombres avec beaucoup plus de chiffre après la virgule, pour évaluer les erreur réels, car je soupçonne 0,66666667 d'être une erreur d'arrondi lié au formatage, plutôt qu'une erreur de double.
Après si l'imprécision reste trop grande, j'ai peur qu'il n'y ai pas solution toute faite a ce problème. Tu peu aller voir sur ce lien (merci Mongaulois ):
http://cpp.developpez.com/faq/cpp/?p...ions_flottants
En espérant que tu y trouvera ton bonheur.

[droggo]

Hia,

Comme tu l'as déjà trouvé, c'est inhérent à la représentation des nombres réels.

Tu peux gagner en précision en passant de float à double, et encore gagner en utilisant une librairie multi-précision (GMP, par exemple), mais il y aura toujours une limite, vu que quelque soit l'intervalle que tu veux utiliser (en dehors d'un ensemble vide, et d'un ensemble ne contenant qu'un élément, bien entendu), il contient une infinité de nombres réels.

Et l'infini n'est pas représentable sur nos machines...

[Obsidian]

il me faut une partie de code pr corriger mes resultats de facon a prendre en considération cette imprecision due au calcul des flottant.

j espere que j ai bien decrit le pb. ca na pas de rapport avec mon code mais avec les possibilités du langage et de l ordinateur. je sai vraiement pas cmt faire

Malheureusement, prendre en compte ce genre de chose fait partie du métier. L'algorithme le plus « propre » d'un point de vue purement mathématique n'est pas toujours le meilleur sur le plan technique, spécialement parce que le premier fait complètement abstraction de la manière dont le calcul doit être mené.

Même en utilisant des nombres à virgule flottante dont la taille est très grande - voire elle-même flottante - tu ne pourras jamais coder 1/3, par exemple, sans imprécision.

Ça veut dire que ton code doit être conçu pour faire le maximum de calcul symbolique lui-même, comme tu le ferais sur papier, et reporter à la dernière étape la détermination effective des valeurs.

[Matthieu Brucher]

Mon problème est que avec c++ la somme des probas est diferente de 1.

Bienvenu dans le monde fantastique des mathématiques appliquées. Ce que tu demandes n'est pas possible avec une représentation finie des nombres comme celle qui est présente dans tous les langages (impossible de représenter pi, e, ...)

[loufoque]

Le phénomène où les approximations s'accumulent s'appelle l'instabilité numérique.
Mais là, en fait, tu n'accumules rien. C'est juste que 1-epsilon et 1 c'est la même chose en flottant.

[Alp]

Maintenant, voici 2 solutions... qui valent ce qu'elles valent.

- Tu additionnes les probas et tu calcules la différence entre 1 et ces probas... Si c'est inférieur à un certain epsilon (10^(-N)), tu fais comme si c'était 1...

- Tu crées une classe pour encapsuler tes probas sous forme p/q (rationnel), en espérant pour toi que tu calcules tes probas grâce à des formules du type nombre_de_cas_favorable/nombre_de_cas_possibles et que les autres s'en déduisent avec des calculs qui permettent de garder ce type de calculs.

[adilou1981]

merci tous pour vos réponses , je vais essayer d'appliquer ce que vous me proposez même cela parait flou d'un premier abord, y en a qui me propose une librairie d'autre un epsilon.

[Alp]

Une bibliothèque te permettrait d'aller très très très loin dans les décimales, ce qui te rapprocherait de l'idéal.
L'epsilon te permettrait lui d'arrondir un peu les angles, de faire en sorte que ça tourne à peu près rond ! Ceci n'est pas absolument pas en contradiction avec la solution de la bibliothèque !
Enfin, les rationnels permettrait de calculer de manière exacte (puisqu'on n'a pas de représentation décimale) mais ça serait un chouilla plus lent.

[adilou1981]

on ma proposé la bibliothèque GMP y en a d'autres?

[droggo]

Mae,

D'un autre côté, utiliser des double te donne environ 16 chiffres significatifs.

As-tu réellement besoin de mieux que ça ?

Tu n'auras jamais de calcul exact si tu utilises des réels, quelle que soit la précision utilisée, car tu finiras toujours par atteindre la limite selon tes valeurs.

Il faut accepter les petits écarts dus à la représentation limitée des réels, sinon, on n'a plus qu'à tous jeter nos ordis, sauf à ne plus utiliser de calculs avec des réels.

[Obsidian]

Mae, D'un autre côté, utiliser des double te donne environ 16 chiffres significatifs. As-tu réellement besoin de mieux que ça ?

Le problème est que les erreurs peuvent se cumuler, spécialement dans le cas de boucles, ce qui est fréquent en proba/stats. Si on considère que le dernier bit de chaque double est imprécis et que l'on fait 80 multiplications successives, alors le flou gagne peu à peu tous les bits de la mantisse ...

[Matthieu Brucher]

on ma proposé la bibliothèque GMP y en a d'autres?

Ca ne résoudra pas tes problèmes, comme je l'ai dit. Tu dois d'abord apprendre à faire de l'analyse numérique.

[Florian Goo]

Plutôt que d'utiliser des double, pourquoi ne pas sommer des entiers et vérifier que la somme vaut bien le nombre de tests ?

[adilou1981]

Plutôt que d'utiliser des double, pourquoi ne pas sommer des entiers et vérifier que la somme vaut bien le nombre de tests ?

Merci d'expliquer d'avantage

[Florian Goo]

Un exemple, sachant que je ne sais pas sur quoi portent tes probas :

Tu traites les résultats d'un sondage sur la couleur préférée des gens. Mettons que 480 personnes ont répondu au sondage :
- Bleu : 209 personnes, soit 0,435416667
- Rouge : 98 personnes, soit 0,204166667
- Vert : 63 personnes, soit 0,13125
- Autre : 110 personnes, soit 0,229166667

Au lieu de faire :
0,435416667 + 0,204166667 + 0,13125 + 0,229166667 = 1,000000001
Tu fais :
209 + 98 + 63 + 110 = 480

[droggo]

Hao,

Le problème est que les erreurs peuvent se cumuler, spécialement dans le cas de boucles, ce qui est fréquent en proba/stats. Si on considère que le dernier bit de chaque double est imprécis et que l'on fait 80 multiplications successives, alors le flou gagne peu à peu tous les bits de la mantisse ...

Alors, la seule solution est d'utiliser des entiers (en gérant des rationnels, par exemple), ou des réels de précision infinie ().

Il faut bien faire la part des choses à un moment ou un autre. Le problème de la représentation des réels est irréductible, tout ce qu'on peut faire est de reculer la limite, et ça coûte rapidement du temps de calcul.

[loufoque]

Travailler avec des rationnels ça marche que si tu ne manipules que des polynomes.
Si tu fais un cos/sin ou un log/exp, tu ne peux pas avoir de valeur exacte.

[droggo]

Hao,

Travailler avec des rationnels ça marche que si tu ne manipules que des polynomes.
Si tu fais un cos/sin ou un log/exp, tu ne peux pas avoir de valeur exacte.

Ben oui, quand je dis que le problème des réels est irréductible ...

[HanLee]

Calcul formel, ya que ça de vrai !