Discussion :

[bolhrak]

Bonsoir tout le monde,

Suite à la lecture de différents articles sur le codage binaire des nombres flottants, je me posais une petite question par rapport aux algorithmes/fonctions de la stl ; operator== ne fonctionnant pas pour les double, de même que operator< et operator> (ce qui m'amène à une première question : pourquoi les avoir implémenter dans le langage s'ils ne fonctionnent pas ?) qu'en est-il pour les algorithmes de tri et les opérateurs d'égalités des conteneurs pour les double ? Par exemple pour un vector, j'imagine que l'operator==, en plus de comparer la taille, compare les éléments un à un ? Dans le cas de double, utilise-t-il un algo spécifique pour la comparaison, ou bien se contente-t-il d'un appel à operator== ? Même question pour les algorithems de tri faisant appel auix opérateurs > et <.

Merci d'avance.

[Sylvain Togni]

Les opérateurs de comparaison fonctionnent parfaitement bien avec les double, où as tu vu le contraire ?

[bolhrak]

http://hal.archives-ouvertes.fr/hal-00128124/fr/
http://docs.sun.com/source/806-3568/ncg_goldberg.html
(voir l'article en pdf)

Sinon tu peux également tester le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
int main(int argc, char* argv[]) {
 
double a = 3.6;
double b = 4.5;
double c = 8.1;
 
if(a + b == c) {
    std::cout << "a+b=c" << std::endl;
}
else {
    std::cout << "a+b != c" << std::endl;
}
 
if(a == c-b) {
    std::cout << "a = c-b" << std::endl;
}
else {
    std::cout << "a != c-b" << std::endl;
}
 
return 0;
}

Avec gcc 4.1.2, ce programme compilé en debug affiche :
a +b = c
a != c-b

Bref l'opérateur== pour les double fait une comparaison bit à bit alors que les calculs sur les doubles + le problème d'underflow amènent des arrondis.

[r0d]

En effet, il y a des problèmes sur les nombres à virgule. Idem avec le type float. Cela provient de la façon dont est codé la représentation des nombres à virgules.

Voir la faq à ce sujet.

[bolhrak]

J'imagine donc que toutes les fonctions de comparaison des conteneurs standards sont à refaire à la main pour les double ?

Et que les algos de tri par défaut (donc sans foncteur de comparaison) ne fonctionnent pas lorsque la séquence d'entrée est une séquence de double ?

[JolyLoic]

Je ne vois pas en quoi ça poserait quelque problème que ce soit pour trier des nombres en flottant. Il n'y a aucun problèmes avec les opérateurs de comparaisons. Le problème est avec les opérations, qui te font manipuler des doubles qui ne sont pas ceux que tu pensais manipuler.

Donc, si tu veux trier un vecteur de doubles dans l'ordre, pas de problèmes.

Si tu veux te servir de doubles comme de clef dans une map, et que ces doubles ne sont pas issus de calculs, ça peut aussi le faire, mais en pratique, je ne recommanderais pas.

[Mat007]

Il n'y a pas vraiment de "problème" sur les calculs sur les flottants, mais il y a des subtilités, oui ça c'est sûr.

J'imagine donc que toutes les fonctions de comparaison des conteneurs standards sont à refaire à la main pour les double ?

Et que les algos de tri par défaut (donc sans foncteur de comparaison) ne fonctionnent pas lorsque la séquence d'entrée est une séquence de double ?

D'un pur point de vue pragmatique on peut dire que les comparaisons fonctionnent parfaitement.
C'est juste que, contrairement à ce que notre cerveau pense être la vérité depuis le CM2, 1.1 - 0.1 ne donne pas 1 ! Mais ce n'est pas vraiment lié aux comparaisons à la limite.

Après tout dépend de ce que tu veux faire avec tes conteneurs de doubles...

MAT.

[bolhrak]

Je ne vois pas en quoi ça poserait quelque problème que ce soit pour trier des nombres en flottant. Il n'y a aucun problèmes avec les opérateurs de comparaisons. Le problème est avec les opérations, qui te font manipuler des doubles qui ne sont pas ceux que tu pensais manipuler.

En effet le problème ne vient pas des comparaisons mais des opérations. Mais dans la mesure où la plupart des comparaisons que je vais devoir effectuer s'appliquent à des résultats de calcul, il y aura tout de même un problème ; même si je n'ai pas été précis sur l'origine du problème, le résultat est le même : mes comparaisons ne donneront pas ce que je souhaite.

Donc, si tu veux trier un vecteur de doubles dans l'ordre, pas de problèmes.

Effectivement dans ce cas pas trop de souci, de toute manière l'algorithme sort ne garantit pas la conservation de l'ordre pour des éléments égaux, donc s'il considère des éléments à priori égaux (j'entends par là tels qu'on les verrait si c'était des réels) comme non égaux ça ne posera pas de problèmes. Par contre l'algorithme unique ne doit pas donner les bons résultats du coup (je parle toujours du cas ou mon vector est rempli par des double issus de résultats de calcul).

C'est juste que, contrairement à ce que notre cerveau pense être la vérité depuis le CM2, 1.1 - 0.1 ne donne pas 1 !

Je nuancerais en disant que ce n'ai pas vrai dans le cadre de l'informatique, où les nombres réels ne peuvent pas être représentés avec une précision infinie. Dans le cas des réels, ce qu'on connaît depuis le CM2 reste vrai (c'était juste pour le plaisir de pinailler )

[Sylvain Togni]

int main(int argc, char* argv[]) {

double a = 3.6;
double b = 4.5;
double c = 8.1;

if(a + b == c) {
std::cout << "a+b=c" << std::endl;
}
else {
std::cout << "a+b != c" << std::endl;
}

if(a == c-b) {
std::cout << "a = c-b" << std::endl;
}
else {
std::cout << "a != c-b" << std::endl;
}

return 0;
}

Le problème n'est ni avec les opérations ni avec les comparaisons, le problème est dans la représentation des double. Ils ne représentent qu'une (petite) partie des réels, de même que les entiers. Remplace "double" par "int" dans le code ci-dessus, dira-tu de la même manière que les comparaisons entre entiers ne fonctionnent pas ?

[bolhrak]

Bien sûr que non.

Je me suis peut être mal exprimé au début du poste, et comme je l'ai dit effectivement l'errer ne vient pas des opérateurs eux mêmes. Mais le résultat est le même : si je veux comparer deux doubles résultant de calcul, je n'aurais pas forcément le résultat attendu.

Bref ma question était de savoir si la STL tenait compte de ce genre de choses, et apparemment non

Merci beaucoup pour les réponses