Précision en C++ : est ce que == suffit?

**rmaker** · 08/07/2012, 22h33

Bonjour,

J'ai une question qui peut paraitre naïve, mais je me demande s'il existe des cas où il faut remplacer des tests d'égalité sur des nombres par des tests du type

Code :

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

1
2
3
4
5
6
7
8
 
#define precision 0.000001
 
bool isEquals(long double a, long double b) {
 long double diff = a - b;
 if (diff < 0.0) diff = - diff;
 return diff < precision;
}

Je code une application qui manipule beaucoup d'équations linéaires, et j'ai (pour l'instant) toujours pu valider mes tests avec des égalités (==) et pas des tests de distance comme ci dessus.

Je vous demande donc si:

vous avez eu le problème d'erreurs dans les calculs? Et si oui, comment vous l'avez résolu?
Si on peut avoir besoin du code (moche) ci dessus?
Et si == suffit toujours, alors pourquoi?

Merci

**rmaker** · 08/07/2012, 22h39

Un premier lien permet d'affiner ma question: http://www.developpez.net/forums/d82...entifique-cpp/

Ma question porte donc sur une application " de gestion normale", avec un besoin de décimales justes de 6 ou 7. Est ce que dans ce cas, un test de distance se justifie pour vous?

**Obsidian** · 09/07/2012, 01h06

Hello,

La comparaison de deux flottants du même type se fait bit à bit, donc l'expression « a == b » est tout-à-fait sûre en elle-même. Les premières difficultés viennent des conversions de types. Par exemple :

Code C++ :

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
#include <iostream>
 
using namespace std;
 
int main (void)
{
    double x = 3.0 / 7.0;
    float  y = 3.0 / 7.0;
    double z;
 
    z = y;
 
    if (x==y) cout << "X et Y sont égaux" << endl;
    else      cout << "X et Y sont différents" << endl;
 
    return 0;
}

Le programme ci-dessus renvoie « différent » même lorsque le nombre est promu à un type plus large, parce que le reste de la mantisse de z est comblé avec des zéros là où celle de x est remplie de décimales valides.

Un autre cas célèbre est celui décrit ici : http://docs.oracle.com/cd/E19957-01/...dberg.html#929

Deux nombres largement au-dessus des limites minimum de représentation et différents entre eux, et qui seront donc signalés comme tels par « == » peuvent quand même afficher une différence nulle car celle-ci est trop petite, elle, pour pouvoir être représentée.

Il faut également tenir compte des progressions exponentielles car, dans ce cas, une imprécision multipliée n fois par elle-même peut vite devenir significative.

Enfin, ça ne sert pas à grand chose d'utiliser des « long double » si c'est pour s'en tenir à une précision de 7 chiffres maximum. Des float suffiraient. Donc, en utilisant des double qui sont par ailleurs utilisés par défaut par le compilo, tu devrais pouvoir t'offrir des marges qui te garantissent la précision dont tu as besoin.

**Joel F** · 09/07/2012, 09h10

On ne compare jamais des reels avec une distance arbitraire absolue. SOit on calcule une distance relative soit on calcule des ULPs.

cf: http://floating-point-gui.de/

**rmaker** · 09/07/2012, 14h05

Merci pour vos réponses. Le lien sur le calcul flottant est une bonne ressource.

Du coup, si on réalise beaucoup de calculs, le test d'égalité peut échouer alors que "fonctionnellement", les résultats peuvent être les mêmes. C'est ce genre de situation qui me pose problème.

Recommandez vous dans ce cas, comme the floating point guide le suggère, de passer par une librairie de calcul?

**Obsidian** · 09/07/2012, 14h56

Envoyé par rmaker

Du coup, si on réalise beaucoup de calculs, le test d'égalité peut échouer alors que "fonctionnellement", les résultats peuvent être les mêmes. C'est ce genre de situation qui me pose problème.

C'est-à-dire qu'encore une fois, il faut être bien clair sur ce point : si le test d'égalité échoue, c'est quand même lui qui a raison. Il ne peut pas y avoir de faux négatif entre deux flottants de même type lors d'une comparaison puisqu'il n'y a qu'une seule manière, à chaque fois, de représenter un même nombre.

Si tu te retrouves avec une distance nulle à l'usage, c'est parce qu'elle est trop faible pour être représentée et cela doit être mis sur le compte de l'imprécision de calcul, au même titre que tout le reste : ces mêmes imprécisions se cumuleront ou se compenseront tout au long de tes calculs même en fonctionnement « normal ».

Après, utiliser une bibliothèque de calcul, ça dépend essentiellement de ce que tu comptes faire. Il faut que tu nous dises exactement quels genre de calculs tu effectues car si l'exactitude est un problème qui doit tenir à cœur de tout informaticien (on en discutait ici), il est quand même peu probable, dans les faits, que tu te retrouves souvent confronté à ces limites. Les bibliothèques de calcul sont sympa, mais elles vont faire sérieusement chuter tes performances.

**droggo** · 09/07/2012, 17h40

Goe,

Envoyé par Obsidian

il est quand même peu probable, dans les faits, que tu te retrouves souvent confronté à ces limites

Sauf que le résultat d'un calcul dépend directement de l'ordre des opérations qui sont faites, et on se retrouve donc très fréquemment avec des résultats légèrement différents (donc le cas qui nous occupe ici), alors que mathématiquement ils devraient être identiques.

Il faut le prendre en compte, et toujours comparer avec une fourchette d'imprécision (fourchette relative, comme le rappelle Joel F.

Comme c'est facile à faire, on peut parfaitement se passer des bibliothèques de calcul, surtout si on entend par là faire du calcul multi-précision, qui de toute manière conduit au même problème, puisqu'on ne peut faire aucun calcul avec une précision infinie.

**rmaker** · 09/07/2012, 17h49

Merci à tous

Envoyé par droggo

Goe,
Sauf que le résultat d'un calcul dépend directement de l'ordre des opérations qui sont faites, et on se retrouve donc très fréquemment avec des résultats légèrement différents (donc le cas qui nous occupe ici), alors que mathématiquement ils devraient être identiques.

C'est effectivement exactement ma préoccupation.

Envoyé par droggo

Il faut le prendre en compte, et toujours comparer avec une fourchette d'imprécision (fourchette relative, comme le rappelle Joel F.

C'est là que çà m'étonne, ou que je ne comprends pas. Recommandes tu systématiquement de tester si les résultats sont les mêmes ou "presque" les mêmes?
Ce n'est pas le code que je lis d'habitude, où une égalité de valeur est mesurée par == et pas par une fonction spéciale.

Peux tu développer ton point?

Merci

**droggo** · 09/07/2012, 19h33

Keo,

- On connaît le problème de la précision (des valeurs légèrement différentes alors qu'elles devraient être identiques)

- On sait aussi que c'est fréquent

Donc, il faut toujours en tenir compte.

Les beaucoup trop fréquents codes qui n'utilisent que la stricte égalité conduisent obligatoirement à des interprétations plus ou moins erronées.

Je ne vois pas ce qu'il y a à dire de plus.

**Joel F** · 10/07/2012, 07h45

J'avais oublié ce trés bon billet:

http://randomascii.wordpress.com/201...-2012-edition/

**gbdivers** · 10/07/2012, 10h32

Envoyé par Joel F

J'avais oublié ce trés bon billet:

http://randomascii.wordpress.com/201...-2012-edition/

Pour info, la série d'article de Bruce Dawson sur les nombres réels sont en cours de traduction. Le premier article de la série ("Tricks With the Floating-Point Format") devrait être publié la semaine prochaine

**rmaker** · 10/07/2012, 10h39

Merci pour vos réponses (et les liens)

Envoyé par droggo

Les beaucoup trop fréquents codes qui n'utilisent que la stricte égalité conduisent obligatoirement à des interprétations plus ou moins erronées.

Alors, sur la façon de régler le pb, j'ai compris, mais il me reste cette question:

Pourquoi, à votre avis, dans du code, on ne trouve pas plus de tests de "presque" égalité, c'est à dire: