Discussion :

[souviron34]

C'est quoi la definition de DBL_EPSILON?

Norme de la stdlib (float.h) :
http://www.di-mgt.com.au/src/CStdLib.html

<float.h>
FLT_RADIX
FLT_ROUNDS
FLT_DIG
FLT_EPSILON
smallest number x such that 1.0 + x != 1.0
FLT_MANT_DIG
FLT_MAX
maximum floating-point number
FLT_MAX_EXP
FLT_MIN
minimum normalised floating-point number
FLT_MIN_EXP
DBL_DIG
DBL_EPSILON
DBL_MANT_DIG
DBL_MAX
maximum double floating-point number
DBL_MAX_EXP
DBL_MIN
minimum normalised double floating-point number
DBL_MIN_EXP

[EDIT]
et IEEE :

http://www.cs.utah.edu/dept/old/texi...ibrary_28.html

Here is an example showing how the floating type measurements come out for the most common floating point representation, specified by the IEEE Standard for Binary Floating Point Arithmetic (ANSI/IEEE Std 754-1985). Nearly all computers designed since the 1980s use this format.

The IEEE single-precision float representation uses a base of 2. There is a sign bit, a mantissa with 23 bits plus one hidden bit (so the total precision is 24 base-2 digits), and an 8-bit exponent that can represent values in the range -125 to 128, inclusive.

So, for an implementation that uses this representation for the float data type, appropriate values for the corresponding parameters are:


FLT_RADIX 2
FLT_MANT_DIG 24
FLT_DIG 6
FLT_MIN_EXP -125
FLT_MIN_10_EXP -37
FLT_MAX_EXP 128
FLT_MAX_10_EXP +38
FLT_MIN 1.17549435E-38F
FLT_MAX 3.40282347E+38F
FLT_EPSILON 1.19209290E-07F

Here are the values for the double data type:


DBL_MANT_DIG 53
DBL_DIG 15
DBL_MIN_EXP -1021
DBL_MIN_10_EXP -307
DBL_MAX_EXP 1024
DBL_MAX_10_EXP 308
DBL_MAX 1.7976931348623157E+308
DBL_MIN 2.2250738585072014E-308
DBL_EPSILON 2.2204460492503131E-016

[/EDIT]

[stephl]

En effet, je me suis trompé. Je pensais que c'était une constante définie par le programmeur, mais en fait elle fait partie des fichiers d'en-tête.

[Jean-Marc.Bourguet]

"smallest number x such that 1.0 + x != 1.0", ce qui fait que 2.0+DBL_EPSILON == 2.0, donc pour que 3-x < DBL_EPSILON, il faut que x == 3. C'est d'ailleurs de qu'un des nombres a comparerer est >= 0.5.

[souviron34]

exact si tu mets 2.0 en toutes "lettres" dans le test.

Pas si tu le stockes dans une variable.

Le moment où tu mets :

d = (double)2.0

Ce que ça veut dire c'est que la norme garanti que dans d, tu as 2.0 jusqu'à DBL_EPSILON chiffres (dans le cas IEEE 16) après la virgule. Mais rien ne garanti que le 17ième soit un zéro....

Et donc pour tester qu'une valeur stockée dans une variable est égale à 2.0, il faut vérifier avec DBL_EPSILON, car 2.000000000000000120000 n'est pas égal à 2.0...

Et comme ça peut être au dessus ou en dessous, d'où le test
fabs(x-2.0) < DBL_ESPILON

[Jean-Marc.Bourguet]

exact si tu mets 2.0 en toutes "lettres" dans le test.

Pas si tu le stockes dans une variable.

Le moment où tu mets :

d = (double)2.0

Ce que ça veut dire c'est que la norme garanti que dans d, tu as 2.0 jusqu'à DBL_EPSILON chiffres (dans le cas IEEE 16) après la virgule. Mais rien ne garanti que le 17ième soit un zéro....

Rien dans la norme en effet... on est dans la qualite d'implementation. Mais

5.2.4.2.2 impose un modele qui garanti que les entiers sont representables,

6.4.4.2/3 permet qu'une constante corresponde soit au nombre representable le plus proche, soit a un de ses voisins me semble avoir ete introduite pour les cas plus extreme ou il y a trop de chiffres pour faire le calcul precis facilement. Pour indication dams ce sens, 7.20.1.3/9 recommande que s'il y a moins de DECIMAL_DIG, le resultat de strto? soit arrondi correctement.

Et donc pour tester qu'une valeur stockée dans une variable est égale à 2.0, il faut vérifier avec DBL_EPSILON, car 2.000000000000000120000 n'est pas égal à 2.0...

Et comme ça peut être au dessus ou en dessous, d'où le test
fabs(x-2.0) < DBL_ESPILON

A nouveau, vu la definition de DBL_EPSILON et en admettant une base 2, il n'y a pas de nombre representable autre que 2.0 entre 2.0-DBL_EPSILON et 2+2*DBL_EPSILON, donc l'inegalite ne peut etre vraie que si x==2.0.

[souviron34]

A nouveau, vu la definition de DBL_EPSILON et en admettant une base 2, il n'y a pas de nombre representable autre que 2.0 entre 2.0-DBL_EPSILON et 2+2*DBL_EPSILON, donc l'inegalite ne peut etre vraie que si x==2.0.

J'avoue que je ne comprends pas (mais je n'ai jamais appris ni l'hexa, ni l'octal, ni le binaire)...

Si un chiffre à virgule flottante est représenté sur 64 bits, bien sûr qu'il peut y avoir plus de 16 chiffres significatifs.....

C'est bien ce que font les doubles. Si on prend le DBL_EPSILON de IEEE (16 chiffres) :

1.9999999999999998100

(int) de ce chiffre devrait donner 1

alors que

(int) de

1.9999999999999999100

devrait donner 2

car tout ce qui est compris entre

1.9999999999999999000
et
2.000000000000000100

devrait être équivalent à

2.000000000000000000


NOTE: En tous cas, dans tous les programmes de maths où il faut tester sur une égalité(inégalité), il est recommandé de toujours tester par rapport à DBL_ESPILON, le cas où la représentation interne sera EXACTEMENT 2.0 ayant une probabilité de 0.5 * 10e-16.....

[Jean-Marc.Bourguet]

J'avoue que je ne comprends pas (mais je n'ai jamais appris ni l'hexa, ni l'octal, ni le binaire)...

Alors arrete de donner des conseils sur les flottants si tu ne comprends pas ce que j'ai ecrit.

NOTE: En tous cas, dans tous les programmes de maths où il faut tester sur une égalité(inégalité), il est recommandé de toujours tester par rapport à DBL_ESPILON, le cas où la représentation interne sera EXACTEMENT 2.0 ayant une probabilité de 0.5 * 10e-16.....

Il est souvent -- mais pas toujours -- necessaire d'utiliser un intervalle. DBL_EPSILON peut servir a le construire, mais l'utiliser brut comme tu le fais ne sert a rien et est meme problematique. Quelque chose comme

Code :

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

1
2
3
int equal_with_bound(double x, double y, int i) {
   return fabs(x-y) <= i*DBL_EPSILON*(fabs(x)+fabs(y));
}

est necessaire. Il reste a choisir i, et la valeur 1 sera rarement la bonne.

[Thierry Chappuis]

Alors arrete de donner des conseils sur les flottants si tu ne comprends pas ce que j'ai ecrit.



Il est souvent -- mais pas toujours -- necessaire d'utiliser un intervalle. DBL_EPSILON peut servir a le construire, mais l'utiliser brut comme tu le fais ne sert a rien et est meme problematique. Quelque chose comme

Code :

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

1
2
3
int equal_with_bound(double x, double y, int i) {
   return fabs(x-y) <= i*DBL_EPSILON*(fabs(x)+fabs(y));
}

est necessaire. Il reste a choisir i, et la valeur 1 sera rarement la bonne.

Quels critères peut-on considérer pour choisir i de manière judicieuse?

Thierry

[souviron34]

Alors arrete de donner des conseils sur les flottants si tu ne comprends pas ce que j'ai ecrit.

Je me référais à base 2....

Il est souvent -- mais pas toujours -- necessaire d'utiliser un intervalle. DBL_EPSILON peut servir a le construire, mais l'utiliser brut comme tu le fais ne sert a rien et est meme problematique. Quelque chose comme

Code :

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

1
2
3
int equal_with_bound(double x, double y, int i) {
   return fabs(x-y) <= i*DBL_EPSILON*(fabs(x)+fabs(y));
}

est necessaire. Il reste a choisir i, et la valeur 1 sera rarement la bonne.

Avec plus de 3 millions de lignes de maths codées, si tu penses que ta théorie est bonne , tant mieux, mais ma pratique m'indique que ce que je cite marche...

[Ulmo]

C'est bien ce que font les doubles. Si on prend le DBL_EPSILON de IEEE (16 chiffres) :

1.9999999999999998100

(int) de ce chiffre devrait donner 1

alors que

(int) de

1.9999999999999999100

devrait donner 2

Perdu. La valeur 10^-16 n'est qu'un ordre de grandeur. Les deux nombres que tu proposent sont stockés en :
+1.1111111111111111111111111111111111111111111111111111 x 2^0
et
+1.0000000000000000000000000000000000000000000000000000 x 2^1

C'est à dire que tu as l'équivalent de 1.9999999999999 et 2.000000000 qui sont tous les deux "2.0".

[souviron34]

je citais 16 par rapport à la norme IEEE.

Comme le lien ci-dessus mentionne, la stdlib de ANSI C précise que cela dépend de l'implémentation..

[souviron34]

Quels critères peut-on considérer pour choisir i de manière judicieuse?

Thierry

En général tu choisis quelque chose qui ressemble à la précision que tu veux, augmentée de 1 ou 2 chiffres..

10e-6, 10e-8, etc...

En fait je me sers pas de DBL_ESPILON, car trop fin.... Il est rare dans un problème physique d'avoir quelque chose de cette précision.

Donc mes tests sont en général

if ( fabs(x-y) < 1.E-08 ) ou E-06

pour des nombres de 1 à .1+06..

et c'est pareil pour tester une convergence de méthode itérative... Avoir un nombre à une précision supérieure à 1.E-08 est rare (ça existe, et dans ce cas il faut adapter)

[stephl]

Donc mes tests sont en général

if ( fabs(x-y) < 1.E-08 )

Cela correspond à la méthode que l'on m'a enseignée en calcul scientifique.

[Thierry Chappuis]

En général tu choisis quelque chose qui ressemble à la précision que tu veux, augmentée de 1 ou 2 chiffres..

10e-6, 10e-8, etc...

En fait je me sers pas de DBL_ESPILON, car trop fin.... Il est rare dans un problème physique d'avoir quelque chose de cette précision.

Donc mes tests sont en général

if ( fabs(x-y) < 1.E-08 ) ou E-06

pour des nombres de 1 à .1+06..

et c'est pareil pour tester une convergence de méthode itérative... Avoir un nombre à une précision supérieure à 1.E-08 est rare (ça existe, et dans ce cas il faut adapter)

OK, merci! Thierry

[Jean-Marc.Bourguet]

Avec plus de 3 millions de lignes de maths codées, si tu penses que ta théorie est bonne, tant mieux, mais ma pratique m'indique que ce que je cite marche...

Si ta pratique marche, tu ne decris pas ta pratique. Le gros probleme de ce que tu decris est que ta borne ne depend pas de la grandeur de ce qui est compare. Donc si elle est tres petite (allez, d'un ordre de grandeur plus petite que ta borne), tu vas admettre des erreurs relatives importantes, si elle est tres grande (allez, 10E30 fois ta borne), tu vas faire une comparaison d'egalite.

Dans le cas de DBL_EPSILON et de 2, tu te trouverai juste a la limite ou on fait un test d'egalite si tu avais utilise <= (tu aurais pris un flottant plus petit que 2.0 et pas de flottant plus grand). Mais tu utilise <, donc tu fais un test d'egalite.

[Jean-Marc.Bourguet]

En général tu choisis quelque chose qui ressemble à la précision que tu veux, augmentée de 1 ou 2 chiffres..

10e-6, 10e-8, etc...

En fait je me sers pas de DBL_ESPILON, car trop fin....

Qu'est-ce que je viens d'ecrire?

Il est rare dans un problème physique d'avoir quelque chose de cette précision.

Donc mes tests sont en général

if ( fabs(x-y) < 1.E-08 ) ou E-06

pour des nombres de 1 à .1+06..

Et voila que tu indiques que tu changes en fonction de l'ordre de grandeur des nombres a comparer.

[Jean-Marc.Bourguet]

Quels critères peut-on considérer pour choisir i de manière judicieuse?

Cela depend de ton application. Plus tu admets une erreur relative importante, plus i peut etre important. Et suivant les calculs que tu fais, il y a une valeur en dessous de laquelle ca n'a pas de sens de descendre, parce que tu vas avoir des comparaisons qui ne retournerons pas la valeur attendue.

Et il y a des cas (si tu depends de la transitivite de l'egalite par exemple) ou il faut utiliser l'egalite. Et s'assurer alors que les calculs ne l'empecheront pas.

On le fixe soit de maniere empirique (augmentant ou diminuant jusqu'a ce que "ca marche"). Soit on fait une analyse plus precise, c'est tres proche de ce qu'on fait quand on veut savoir quelle influence peut avoir une erreur de mesure sur un resultat derive.

[Thierry Chappuis]

Cela depend de ton application. Plus tu admets une erreur relative importante, plus i peut etre important. Et suivant les calculs que tu fais, il y a une valeur en dessous de laquelle ca n'a pas de sens de descendre, parce que tu vas avoir des comparaisons qui ne retournerons pas la valeur attendue.

Et il y a des cas (si tu depends de la transitivite de l'egalite par exemple) ou il faut utiliser l'egalite. Et s'assurer alors que les calculs ne l'empecheront pas.

On le fixe soit de maniere empirique (augmentant ou diminuant jusqu'a ce que "ca marche"). Soit on fait une analyse plus precise, c'est tres proche de ce qu'on fait quand on veut savoir quelle influence peut avoir une erreur de mesure sur un resultat derive.

Merci pour ces précisions. Je comprends mieux. Thierry

[souviron34]

En tous cas, Jean-Marc, pour terminer là dessus, ta première réponse est effectivement fausse par rapport à la question originale :

Un truc me tracasse depuis longtemps, on sait qu'un flottant n'a pas de valeur absolument determinée

Si.

Les entiers sont exactement representables dans tous les formats de flottants que je connais. Autrement dit 3.0 sera toujours 3.0.

et la norme définit correctement une précision en deçà de laquelle il n'est pas possible de spécifier avec exactitude que le résultat d'un calcul qui devrait donner 2.0 ne donnera pas forcément 2.0... mais 2.0 +- DBL_EPSILON.

Et d'ailleurs la question n'était pas par rapport aux entiers, mais aux flottants, ce dont on vient de parler pendant le thread.

En dehors de ça, nous sommes d'accord.

[Thierry Chappuis]

En tous cas, Jean-Marc, pour terminer là dessus, ta première réponse est effectivement fausse par rapport à la question originale :





et la norme définit correctement une précision en deçà de laquelle il n'est pas possible de spécifier avec exactitude que le résultat d'un calcul qui devrait donner 2.0 ne donnera pas forcément 2.0... mais 2.0 +- DBL_EPSILON.

Et d'ailleurs la question n'était pas par rapport aux entiers, mais aux flottants, ce dont on vient de parler pendant le thread.

En dehors de ça, nous sommes d'accord.

Selon ce que j'ai compris des remarques de Jean-Marc Bourguet, la norme impose que le système de représentation des nombres flottant soit capable de représenté de manière exacte n'importe quel entier. Je ne m'y connais pas trop, mais il semble que cela soit le cas avec IEEE 754 où il me semble que tous les entiers de type int peuvent être représentés de manière exacte par un flottant double précision. En particulier, les entiers 2.0, 3.0, et 6.0 sont représentable exactement. Donc, le calcul 2.0 * 3.0 est également représentable exactement, et je crois que c'est garantit:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
La représentation IEEE 754 de 2.0 est:
0100000000000000000000000000000000000000000000000000000000000000
---------------------------------------
La représentation IEEE 754 de 3.0 est:
0100000000001000000000000000000000000000000000000000000000000000
---------------------------------------
La représentation IEEE 754 de 2.0 est:
0100000000000000000000000000000000000000000000000000000000000000
---------------------------------------
La représentation IEEE 754 de 6.0 est:
0100000000011000000000000000000000000000000000000000000000000000
---------------------------------------
La représentation IEEE 754 de 2.0 * 3.0 est:
0100000000011000000000000000000000000000000000000000000000000000

Donc, si j'ai bien compris ce qui a été dit:

Code :

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

1
2
3
4
5
6
a = 2.0 * 2.2;
 
if (a == 4.4)
{
     /* traitement */
}

N'est pas garantit de fonctionner car 2.2, ni 4.4 ne sont représentablesexactement. Par contre

Code :

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

1
2
3
4
5
6
a = 2.0 * 3.0;
 
if (a == 6.0)
{
    /* Traitement */
}

est garantit de fonctionner!

Thierry