test sur un double

Bonsoir,

question basique mais :
j'ai besoin à l'aide d'un test de m'assurer qu'un double (rho) soit strictement inférieur à 1.0, faire le test

rho >= 1.0 est mauvais(je pense); comment choisir la précision(epsilon) du test
de type rho >= 1.0-epsilon

question connexe: remplacer le test "rho > 1.0" par "rho >= 1.0" dans le but de s'assurer que rho est strictement inférieur à 1.0 est bien ridicule?

Effectivement,

rho >= 1.0 ne te donnera pas le resultat souhaiter.

c'est

rho < 1.0

qu'il faut utiliser.
Ensuite, quand a la precision, je pense que ceux qui ont develloper le C++ ont du y penser.
Enfin, je ne sais pas, donc je m'avance en pente glissante.

Si j'etait toi, (mais je ne le suis pas) je prendrait comme acqui que 1.0 vaut effectivement 1.0000000 ... (je ne sais plus combien on en stock).

Bei,

Citation:

---

Envoyé par SofEvans

Effectivement,

rho >= 1.0 ne te donnera pas le resultat souhaiter.

c'est

rho < 1.0

qu'il faut utiliser.

---

C'est le même résultat, simplement inversé. Tout dépend donc de ce qu'on veut faire. :)

ma question ne portait pas sur le sens de l'inégalité mais sur le sens du test ;)

si j'écris rho = 1.0 rien ne garantit que sa représentation en machine ne soit égale à 1.0, rho peut valoir 1.000000001, et c'est d'autant plus vrai si la valeur 1 a été affecté via une cascade de calcul.

Sachant que tester si un double vaut 1 par (d == 1.0) est très mauvais, à mon avis c'est le même problème là, non?

Citation:

---

Envoyé par mangeclous

si j'écris rho = 1.0 rien ne garantit que sa représentation en machine ne soit égale à 1.0, rho peut valoir 1.000000001, et

---

1 est exactement représentable avec la norme classique sur les flottants, donc si tu écris rho = 1, tu es certain que rho vaut exactement 1.

Citation:

---

Envoyé par mangeclous

c'est d'autant plus vrai si la valeur 1 a été affecté via une cascade de calcul.

---

Là, c'est différent. Si tu donnes à rho le résultat d'une chaîn e de calculs, et que tu crois que ce résultat devrait être 1, il est possible que ce ne soit pas le cas est que tu aies une valeur approchée.

Citation:

---

Envoyé par mangeclous

Sachant que tester si un double vaut 1 par (d == 1.0) est très mauvais, à mon avis c'est le même problème là, non?

---

Je ne vois pas de problèmes à écrire if (rho<1) {...}. Mais il faut juste t'attendre à ce que ce test soit vrai si tu as assigné à rho la valeur 0.1+0.1+0.1+...+0.1.

Citation:

---

Envoyé par JolyLoic

1 est exactement représentable avec la norme classique sur les flottants,

---

Je ne connais pas de representation de flottants incapable de representer exactement de petits entiers (pour une notion de petit en rapport avec la taille de leur mantisse).

Citation:

---

Envoyé par JolyLoic

1 est exactement représentable avec la norme classique sur les flottants, donc si tu écris rho = 1, tu es certain que rho vaut exactement 1.

---

bizarre je crois me souvenir lors de debugs qu'une variable censée valoir 1 valait dans un add watch 1.000000000001, je te fais confiance.

Citation:

---

Je ne vois pas de problèmes à écrire if (rho<1) {...}. Mais il faut juste t'attendre à ce que ce test soit vrai si tu as assigné à rho la valeur 0.1+0.1+0.1+...+0.1.

---

OK

Thanks

Salut, je fais pas mal de calcul numérique. Pour tester l'égalité entre 2 doubles, il faut passer par une valeur absolue :

Code:

---

1 2	if(fabs(rho - 1.) < EPS) blabla

---

dans la pratique je fais un

Code:

---

1 2	#define EPS 1e-10

---

sinon, si tu fais du calcul, n'utilise pas les floats mais plutôt les doubles

Je suis surpris de la valeur de ton epsilon... Elle me parait soit trop grande, soit trop petite..

Citation:

---

Envoyé par JolyLoic

Je suis surpris de la valeur de ton epsilon... Elle me parait soit trop grande, soit trop petite..

---

Salut,

Sur quoi bases-tu cette remarque? je pensais que cela dépendait principalement de ce que tu fais dans ton programme, cela me paraissait difficile d'établir une règle générale.
Tu mettrais combien pour les double et combien pour les floats?

Salut,

Citation:

---

Envoyé par mangeclous

Salut,

Sur quoi bases-tu cette remarque? je pensais que cela dépendait principalement de ce que tu fais dans ton programme, cela me paraissait difficile d'établir une règle générale.
Tu mettrais combien pour les double et combien pour les floats?

---

Sans doute sur le fait que, comme toute décision arbitraire, il est possible de la remettre en question ;)

Dans certains cas, 10^-10 sera largement superflu, dans d'autres, ce sera amplement insuffisant ;)

Pourquoi ne pas faire confiance au compilateur et utiliser numeric_limits<type>::epsilon, à moins que tu n'aies une raison valable et cohérente pour placer la limite à une valeur différente :question:

En fait, c'est plus compliqué que ça...

La comparaison de 2 flottants (sans préciser le type "float" ou "double") dépend de leurs valeurs respectives.
Si a = 1.2e200 et b = 1.3e200, on comprend tout de suite que fixer un epsilon à 1e-10 ou 1e-6 ne change pas grand chose !
Il faut connaître le nombre de chiffres significatifs des types flottant.
Par exemple, un double a (à peu près) 16 chiffres significatifs. Donc epsilon doit être au moins d'ordre max(a,b)/10^16.

Comme il faut prévoir pas mal de marge à cause des accumulations d'erreurs d'arrondi (lors de calculs en cascade), disons que epsilon = max(a,b)/10^10 est pas mal...

Enfin, il faut savoir que certains problèmes sont sans solution avec des flottants.
Par exemple :

Code:

---

1 2 3

double a = 1e200 ; double b = a + 1 ; if (b == a) ...

---

Ce test sera évalué à vrai malgré tous les epsilons de la terre car 1 est trop petit par rapport au 10^200 stocké dans les variables (loin après le 16eme chiffre significatif) et donc ne sera pas pris en compte.
Quand on est confronté à ce genre de problème, il faut repenser tout son code !

Citation:

---

Envoyé par koala01

Sans doute sur le fait que, comme toute décision arbitraire, il est possible de la remettre en question ;)

Dans certains cas, 10^-10 sera largement superflu, dans d'autres, ce sera amplement insuffisant ;)

---

Tout à fait, et d'ailleurs, un epsilon relatif sera souvent plus pertinent qu'un epsilon absolu.

Citation:

---

Envoyé par koala01

Pourquoi ne pas faire confiance au compilateur et utiliser numeric_limits<type>::epsilon, à moins que tu n'aies une raison valable et cohérente pour placer la limite à une valeur différente :question:

---

C'est généralement une fausse bonne idée. L'epsilon du compilateur indique l'optimal de précision qu'il peut obtenir. Ça n'a généralement aucun rapport avec la précision que l'on estime que nos calculs vont donner, ou dont notre domaine d'application va se contenter.

si le double sur lequel je fais un test est obtenu après un milliard d'opérations élémentaires, par exemple des additions, l'erreur serait de un milliard fois la précision initiale. Je peux espérer que les erreurs vont s'annuler statistiquement mais si j'envoie une fusée sur la lune j'ai intérêt à savoir maîtriser convenablement cette erreur, non ?

Citation:

---

Envoyé par mangeclous

si le double sur lequel je fais un test est obtenu après un milliard d'opérations élémentaires, par exemple des additions, l'erreur serait de un milliard fois la précision initiale. Je peux espérer que les erreurs vont s'annuler statistiquement mais si j'envoie une fusée sur la lune j'ai intérêt à savoir maîtriser convenablement cette erreur, non ?

---

J'espère.

Le problème est qu'on fille les flottants à des gens sans leur donner le cours d'analyse numérique qui devrait permettre de comprendre comment s'en servir.

Citation:

---

Envoyé par Jean-Marc.Bourguet

J'espère.

Le problème est qu'on fille les flottants à des gens sans leur donner le cours d'analyse numérique qui devrait permettre de comprendre comment s'en servir.

---

En fait, ca va au delà de l'analyse numérique. En général, les gens même avec des profils scientifiques poussés sont peu sensibilisés à la problématique de l'incertitude de mesure. La fusée atteindra Mars plutôt que la Lune non parce l'algo a fait l'impasse sur la problématique de la propagation des erreurs mais parce que les données initiales étaient de toute façon déjà entachées d'une erreur trop importante.

Citation:

---

Envoyé par 3DArchi

En général, les gens même avec des profils scientifiques poussés sont peu sensibilisés à la problématique de l'incertitude de mesure.

---

Je dois avoir eu une formation exceptionnelle -- je ne me souviens pas de TP de physique ou de chimie où cet aspect n'intervenait pas.

Citation:

---

Envoyé par Jean-Marc.Bourguet

J'espère.

Le problème est qu'on fille les flottants à des gens sans leur donner le cours d'analyse numérique qui devrait permettre de comprendre comment s'en servir.

---

Que connais-tu comme bon cours d'analyse numérique qui permet d'acquérir cette compréhension?

Citation:

---

Envoyé par mangeclous

Que connais-tu comme bon cours d'analyse numérique qui permet d'acquérir cette compréhension?

---

Non. C'est loin d'être un domaine où je suis expert.

Je sais qu'il y a des bouquins qui causent d'analyse numérique & calculs scientifiques en C++... mais ne sais pas ce qu'ils valent.

Citation:

---

Envoyé par Alp

Je sais qu'il y a des bouquins qui causent d'analyse numérique & calculs scientifiques en C++... mais ne sais pas ce qu'ils valent.

---

J'en connais, mais c'est soit des maths, soit de l'info. On aborde pas vraiment le sujet, finalement le language n'est pas important, je souhaite comprendre la problèmatique de représentation des réels sur une machine.

J'ai ces 2 références en tête :
http://docs.sun.com/source/806-3568/ncg_goldberg.html
http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

merci pour les références je vais lire ça ce we. Sinon au sujet de

Citation:

---

Envoyé par JolyLoic

1 est exactement représentable avec la norme classique sur les flottants, donc si tu écris rho = 1, tu es certain que rho vaut exactement 1.

---

J'ai fait un add-in pour excel en cpp, où je passe en paramètre 0.1 pour une valeur, eh bien lors d'un debug j'ai pu constaté via un addwatch que la variable ne valait pas 1.0 exactement, quid ?

Je ne suis pas certain de ce que tu veux dire. 1 est représentable exactement. 0,1 n'est pas représentable exactement. Donc 0,1 + 0,1 + ... + 0,1 (10 fois) ne vaudra pas 1.

zut, je me suis planté, c'était 0.1 donc c'est normal...