Calcul -> NAN en C++

**Spout** · 01/08/2008, 11h33

Bonjour � tous!

Question de la mort qui tue: comment savoir que le r�sultat d'une op�ration est invalide?
Je m'explique: si par exemple je fais une division par 0, comment je peux savoir que le contenu de ma variable n'est pas valide (�quivalent NAN sur Excel par exemple)?

Contexte: j'ai r�cup�r� une DLL qui fait des calculs. Il y a des fonctions export�es qui renvoient des r�sultats (double) en fonction des param�tres d'entr�e. Sauf que la personne qui a fait cette DLL n'a pa pr�vu les cas de calculs ambig�es (division par 0, ...). R�sultat, d�s que je formate le r�sultat � probl�me dans une cha�ne de caract�res, je me r�cup�re un magnifique "1.#INF".

Y-a-t'il moyen de le savoir avant de formater le texte et faire une recherche sur le caract�re '#' par exemple? Est-ce que je peux le savoir rien qu'avec la variable de retour?

Merci d'avance.

**Mat007** · 01/08/2008, 12h04

Salut,

Une division par z�ro produit un nombre tout � fait valide en C++, tu peux le tester avec std::numeric_limits< double >::infinity() par exemple.

Pour tester NaN tu peux tester si un nombre est bien �gal � lui-m�me (NaN est diff�rent de lui-m�me).

La repr�sentation obtenue sous forme de cha�ne de caract�res avec les iostreams d�pend de la plate-forme par contre...

MAT.

**BainE** · 01/08/2008, 14h01

Envoy� par Mat007

Une division par z�ro produit un nombre tout � fait valide en C++

Ca plante une division par zero, en tout cas avec gcc et le compilo de visual 2005.

**Frifron** · 01/08/2008, 14h27

a l'execution, a partir d'une variable, ca ne plante pas. Par contre j'ai remarqu� que ca faisait ramer le code a fond (enfin je ne c pas si c'etait la division en elle meme ou les calcul avec l'infini r�sultants)

**Mat007** · 01/08/2008, 14h28

Envoy� par BainE

Ca plante une division par zero, en tout cas avec gcc et le compilo de visual 2005.

Hmm pas chez moi...

Avec VC2005 ce test passe :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
BOOST_AUTO_TEST_CASE( DivisionByZero )
{
    static const float ZERO = 0.f;
    BOOST_CHECK_EQUAL( std::numeric_limits< float >::infinity(), 1.f / ZERO );
}

Avec g++ sous cygwin :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
#include <iostream>
 
int main()
{
  static const float ZERO = 0.f;
  if( std::numeric_limits< float >::infinity() == 1.f / ZERO )
    std::cout << "OK" << std::endl;
  return 0;
}

En faisant :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
$ g++ -Wall divide_by_zero.cpp
divide_by_zero.cpp: In function `int main()':
divide_by_zero.cpp:6: warning: division by zero in `1.0e+0f / 0.'
 
$ ./a.exe
OK

Qu'est ce que tu entends exactement par "�a plante" ?

MAT.

**nicroman** · 02/08/2008, 03h16

Une division par un flottant nul ne 'plante' pas (n'�met pas d'exception si c'est ce que tu voulais dire), mais raise un flag.
Une division par un entier nul, par contre, envoie une exception CPU.

**Aszarsha** · 02/08/2008, 04h35

Envoy� par Frifron

Par contre j'ai remarqu� que ca faisait ramer le code a fond (enfin je ne c pas si c'etait la division en elle meme ou les calcul avec l'infini r�sultants)

Oui le code devient tr�s lent, mais pour aucune des deux raisons cit�es. Quand tu effectues un calcul avec un NaN (je ne suis pas certain si c'est au moment o� tu l'obtiens ou au moment o� tu l'utilise), le processeur �met une exception mat�riel, qui �met alors une interruption et fait donc passer le processeur en mode noyau (tout en branchant sur l'IRQ enregistr�e, elle-m�me rendant g�n�ralement la main au noyau).
Lorsque tu obtiens des NaN, imagine que ton processus se met � rendre la main au noyau a chaque calcul...

Il y a quelques patchs pour le noyau Linux qui changent l'IRQ qui g�re ce probl�me afin de diminuer la perte de vitesse lors de calculs tr�s intensifs, mais �a ne fait pas des miracles... Sans compter qu'un NaN se propage... Vite.

Envoy� par nicroman

Une division par un flottant nul ne 'plante' pas (n'�met pas d'exception si c'est ce que tu voulais dire), mais raise un flag.
Une division par un entier nul, par contre, envoie une exception CPU.

Si c'est vraiment le cas, ce doit �tre param�trable au lancement du noyau. Sur tous les syst�mes que j'ai utilis�s, ce n'est pas le cas, et des NaN avec des flottant y �mettent bien des interruptions mat�rielles.

**Spout** · 04/08/2008, 12h00

Merci � tous pour vos r�ponses.
Apr�s divers essais, je peux vous dire:

Envoy� par Mat007

Pour tester NaN tu peux tester si un nombre est bien �gal � lui-m�me (NaN est diff�rent de lui-m�me).

Je n'ai pas pu v�rifier, mon retour �tant un double (et le == n'est pas valable sur un double

). Peut �tre sur un int?

Envoy� par Mat007

Envoy� par BainE

Ca plante une division par zero, en tout cas avec gcc et le compilo de visual 2005.

Hmm pas chez moi...

Oui et non

(j'utilise VS). Une division explicite dans le code t'attireras les foudres du compilateur:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

int iProut = 1/0;

error C2124: division ou modulo par z�ro

Une division par 0 "cach�e" n'emp�chera pas la compilation, te produiras �ventuellement un warning (pas syst�matique), mais plantera � l'ex�cution ("XXXX a rencontr� un probl�me et doit fermer....", je suis sous XP):

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
int iNum = 1;
int iDen = 0;
int iQuo = iNum/iDen;

warning C4723: division potentielle par 0

Sauf que dans mon cas, c'est-�-dire la division dans une DLL annexe et le r�sultat renvoy� dans le programme principal, le plantage n'intervient pas, et c'est cet esp�ce de NaN qui m'est renvoy�.

Envoy� par Mat007

Une division par z�ro produit un nombre tout � fait valide en C++, tu peux le tester avec std::numeric_limits< double >::infinity() par exemple.

Effectivement, j'ai v�rifi� et je vais faire comme cela

.
Merci � tous!

**JolyLoic** · 04/08/2008, 12h58

Envoy� par spoutspout

Apr�s divers essais, je peux vous dire:Je n'ai pas pu v�rifier, mon retour �tant un double (et le == n'est pas valable sur un double

).

Bien sur que si il est valable. NAN est garanti �tre le seul double non �gal � lui m�me. Il n'est pas garanti que

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1 == 1

Mais il est garanti que

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1 == 0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1

**Spout** · 04/08/2008, 14h13

Mais ce n'est pas applicable � un retour de fonction car je ne peux pas deviner ce qui me sera renvoy�, et donc par rapport � quoi il me faut tester ce retour (mon but est juste de d�tecter si la valeur est valide, pas si elle est �gale � quelque chose).

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
double dMyVar = MyFonction(...);
 
if(dMyVar == dMyVar)
    cout << "Valide";
else
    cout << "Pas valide";

Si ma fonction me renvoie "1.#INF0000..." (sous Visual, une fois format� en texte) c'est � dire NaN, c'est le "Valide" qui est affich�, ce qui est faux. Donc v�rifier un double en testant s'il est �gal � lui-m�me ne fonctionne pas.
Ou alors je n'ai pas compris ce que vous m'avez sugg�r�

.

D'une mani�re g�n�rale, je ne fais jamais du "==" avec les double car �a pose quand m�me souvent probl�me. Par exemple, dans le test suivant, c'est "pas �gal" qui est affich�:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
double dVal1 = 0.1 + 0.1 + 0.1 + 0.1 + 0.1; // = 0.5
double dVal2 = 1.0 - 0.1 - 0.1 - 0.1 - 0.1 - 0.1; // = 0.5 aussi
 
if(dVal1 == dVal2)
    cout << "égal";
else
    cout << "pas égal";

**Mat007** · 04/08/2008, 14h24

Infinity (INF) et Not-A-Number (NAN) ne sont pas la m�me chose.
L'infini est un nombre, et c'est ce que tu obtiens dans ton cas lors d'une division par z�ro, et tu le testes avec == std::numeric_limits< double >::infinity() (ou avec !=).

MAT.

**Spout** · 04/08/2008, 14h30

OK, j'avais s�rement mal cibl� et/ou expliqu� mon probl�me.

Merci

**Spout** · 04/08/2008, 14h54

Envoy� par Mat007

La repr�sentation obtenue sous forme de cha�ne de caract�res avec les iostreams d�pend de la plate-forme par contre...

Du coup, est-ce le cas �galement pour la repr�sentation d'infini?

**Mat007** · 04/08/2008, 15h05

Envoy� par spoutspout

Du coup, est-ce le cas �galement pour la repr�sentation d'infini?

Oui.

Par exemple avec g++ sous cygwin on aura inf alors que msvc donnera 1.#INF.

MAT.

**Spout** · 25/08/2008, 15h52

Je permets de remonter ce topic, car j'ai un autre probl�me du m�me genre. Le debuggeur de Visual me renvoie non plus 1.#INF, mais 1.#IND. Ceci apparait quand j'effectue un 0/0.
J'ai recherch� du c�t� des std::numeric_limits, mais je n'ai rien trouv� correspondant au IND (comme infinity() pour INF).
J'ai deux questions:

Qu'est-ce que "IND"? Ind�fini? Indivisible?
Comment faire le m�me genre de test que pr�c�demment pour d�tecter le IND?

Merci d'avance.

**Frifron** · 25/08/2008, 16h44

J'imagine que c'est INDEFINITE. 0 / 0 a un r�sultat non d�fini. Ca doit �tre plus ou moins �quivalent a un NaN.

**Spout** · 25/08/2008, 16h46

Envoy� par Frifron

J'imagine que c'est INDEFINITE. 0 / 0 a un r�sultat non d�fini. Ca doit �tre plus ou moins �quivalent a un NaN.

Donc d�tectable avec un quiet_NaN() ?

**Jean-Marc.Bourguet** · 25/08/2008, 17h38

Envoy� par spoutspout

Donc d�tectable avec un quiet_NaN() ?

Comment?

La seule maniere, c'est de voir s'il est egal a lui-meme. Si ce n'est pas le cas, tu as un NaN. En passant, il y a pas mal de NaN differents, en theorie ont pourrait initialiser toutes les variables float/doubles avec un et voir a la fin si on a du calcul qui fait intervenir des variables non initialisees et trouver une d'entre elles -- les operations prenant un ou plusieurs NaN en entree doivent retourner un de ceux-ci comme resultat.

**Spout** · 25/08/2008, 23h49

Envoy� par Jean-Marc.Bourguet

Comment?

Ben de la m�me mani�re que pour le 1.#INF:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
double dProut = 51/0; // forcément ça compilera pas, mais c'est pour illustrer
 
if(dProut == std::numeric_limits<double>::infinity())
    std::cout << dProut << std::endl;

Faudrait que j'arrive � reprosuire ce 1.#IND pour tester quiet_NaN()... Je vais creuser �a

**Jean-Marc.Bourguet** · 26/08/2008, 08h25

Envoy� par spoutspout

Ben de la m�me mani�re que pour le 1.#INF:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
double dProut = 51/0; // forcément ça compilera pas, mais c'est pour illustrer
 
if(dProut == std::numeric_limits<double>::infinity())
    std::cout << dProut << std::endl;