Output de mon code :-1.#IND

Version imprimable

15/12/2008, 23h37
Udani

Output de mon code :-1.#IND

Bonjour,

j'ai écris un code en C++, l' un des résultats (output)que j'avais eu est le suivant:

Code:

-1.#IND

ça veux dire quoi svp?
c'est bizzare, :(
16/12/2008, 09h31
3DArchi

NaN.
Ton calcul échoue (par exemple sqrt(-1) retourne NaN).
16/12/2008, 11h01
befalimpertinent

ça sent la division par zero.
Postes le bout de code qui provoque cette sortie pour qu'on puisse t'en dire plus
16/12/2008, 21h00
JolyLoic

Une division par 0 donnerait un infini, pas un NAN.
16/12/2008, 22h55
Garulfo

Citation:

Envoyé par Udani

Bonjour,

j'ai écris un code en C++, l' un des résultats (output)que j'avais eu est le suivant:

Code:

-1.#IND

ça veux dire quoi svp?
c'est bizzare, :(

C'est la manière dont Microsoft signale un "Quiet NaN". Tu pourras trouver un peu d'explication ici : http://www.cisl.ucar.edu/docs/trap.e...rrortypes.html
Tu as fait une opération qui ne mène pas à un nombre. 3DArchi t'en donnes un exemple. Ça n'a rien de bizarre donc. ;)

Vérifies tes calculs au fur et à mesure, quitte à placer des asserts avant les opérations sensibles. Une bonne activité de débuggage en vue donc.
16/12/2008, 22h56
Garulfo

Citation:

Envoyé par befalimpertinent

ça sent la division par zero.
Postes le bout de code qui provoque cette sortie pour qu'on puisse t'en dire plus

Mauvaise idée. Il faut qu'il cherche par lui-même. Si on l'aide, il retombera dans le piège la prochaine fois. S'il en bave, il va s'en souvenir :mrgreen:
16/12/2008, 23h04
Udani

Merci pour vous réponses. En effet il s'agit d' un valeur "qui n' est pas bonne" et qui est presque nul. J'ai utilisé un autre compiler ( DevC++ au lieu de Visual C++ 2005 express ) qui a donné une valeur qui est : 2.23237e-307 !!!
je vais essayer de vous poster la partie du code concernée.
Mais avant je tiens à vous informer que j'ai pas encore compris ce que fait le debbugeur. Serais t-il possible de connaitre la partie de ma méthode qui est la cause de mon malheur :aie: ? comment ? aidez moi svp!
16/12/2008, 23h49
koala01

Salut,

D'après ce que tu écris, j'aurais tendance à dire que tu essaye de faire une opération mathématique (sans doute une division) avec des valeurs dont l'une au moins n'est pas correctement initialisée.

Si tu travailles avec des structures (ou des classes) pense à respecter scrupuleusement le principe du RAII (Ressource Aquisition Is Initialisation, ou, si tu préfères en français : l'acquisition de ressources est l'initialisation).

Si tu travailles avec des pointeurs, veilles à bien utiliser la valeur "pointée par" ton pointeur, car, autrement, la valeur utilisée sera... le résultat de la conversion de l'adresse en valeur, et tu aura compris que ce n'est sans doute pas ce que tu veux faire ;)

Si, enfin, tu travailles "simplement" avec des variables de types "primitifs", veille à ce que leur valeur soient "cohérentes" avec ce à quoi elles servent.

Peut être devrais tu régler ton compilateur sur un mode "paranoïac" et veiller à trouver une solution pour supprimer chaque avertissement qu'il t'affiche (en commençant par le premier, car il y en a parfois "en cascade" ;) )
17/12/2008, 01h40
Garulfo
Citation:

Envoyé par Udani

[...]
je vais essayer de vous poster la partie du code concernée.
Mais avant je tiens à vous informer que j'ai pas encore compris ce que fait le debbugeur. Serais t-il possible de connaitre la partie de ma méthode qui est la cause de mon malheur :aie: ? comment ? aidez moi svp!

Tu n'as pas besoin d'un débuggeur: apprends à tracer toi même ton programme avant d'utiliser un débuggeur (et par la suite, apprends à utiliser un débuggeur pour ne pas galerer bêtement). Place régulièrement dans ton programme des affichages aux points sensibles. Tu verras avec quelles valeurs tu fais ton calcul. C'est long, pénible et error-prone lorsque tu les enlèves. Mais c'est un bon apprentissage.

Comme je l'ai dit tu peux aussi ajouter des asserts (#include <cassert>)
Code:

1 2 resultat = sqrt(valeur) / coefficient ;
deviendrait, par exemple,
Code:

1 2 3 4 assert (valeur > 0); assert (coefficient != 0); resultat = sqrt(valeur) / coefficient ;
dépendant de ce que tu penses avoir à ce moment du code. Ceci à l'avantage de ne pas demander de modifications de code une fois que tu as fini. Pour ne pas tenir compte des asserts tu rajoutes

Code:

#define NDEBUG

juste avant l'include.

Citation:

Envoyé par koala01

[...]
Peut être devrais tu régler ton compilateur sur un mode "paranoïac" et veiller à trouver une solution pour supprimer chaque avertissement qu'il t'affiche (en commençant par le premier, car il y en a parfois "en cascade" ;) )

C'est un très bon conseil. J'impose toujours à mes étudiants de mettre le maximum d'avertissement (option --Wall) et tous les enlever. Quand on fait des programmes de débutant, on devrait toujours pouvoir le faire.
17/12/2008, 09h34
befalimpertinent

Citation:

Place régulièrement dans ton programme des affichages aux points sensibles

Pas d'accord, modifier le contexte autour de l'erreur c'est la meilleur façon de la perdre. Apprendre à utiliser un debugeur est le meilleur conseil qu'on puisse lui donner.
Avec VS, par exemple, places un point d'arret à un endroit suspect (F9), exécutes en mode Debug ton programme et vérifies les valeurs en exécutant ton code pas à pas(F10) . ça ne devrait par résister trop longtemps.
17/12/2008, 16h45
Jean-Marc.Bourguet

Citation:

Envoyé par befalimpertinent

Apprendre à utiliser un debugeur est le meilleur conseil qu'on puisse lui donner.

Je crois que les opinions varient. Apprendre a se passer du debugueur est a mon avis un meilleur conseil que d'apprendre a s'en servir.

Je ne suis pas de ceux qui les prétendent inutiles mais leur utilité est plus limitée que ne l'affirment ceux qui les prétendent indispensables. Ils sont souvent aussi une perte de temps énorme quand ils ne sont pas la meilleure technique.
17/12/2008, 17h15
3DArchi

Citation:

Envoyé par Jean-Marc.Bourguet

Je crois que les opinions varient.

Effectivement, c'est presque du domaine du troll. A mon sens, si tu maîtrise le debugger, utilise-le de façon privilégiée. Sinon, les bonnes vieilles traces ont aussi du bon. Mais c'est souvent plus laborieux. Mais avant de préférer l'un à l'autre, autant maîtriser son environnement de dev.
17/12/2008, 17h20
Jean-Marc.Bourguet

Citation:

Envoyé par 3DArchi

Effectivement, c'est presque du domaine du troll. A mon sens, si tu maîtrise le debugger, utilise-le de façon privilégiée. Sinon, les bonnes vieilles traces ont aussi du bon. Mais c'est souvent plus laborieux. Mais avant de préférer l'un à l'autre, autant maîtriser son environnement de dev.

Bizarre, mon point de vue est que le debugeur est souvent plus laborieux au final. Plus incremental, donc on veut voir tout de suite et on réfléchit moins a l'aspect d'ensemble; or c'est en reflechissant qu'on trouve les problemes. Ca tient aussi a la nature des bugs recherche -- les miens sont souvent des interactions subtiles ou une vision trop pres du code n'indique pas la nature reelle du probleme.
17/12/2008, 17h24
3DArchi

Citation:

Envoyé par Jean-Marc.Bourguet

Bizarre, mon point de vue est que le debugeur est souvent plus laborieux au final. Plus incremental, donc on veut voir tout de suite et on réfléchit moins a l'aspect d'ensemble; or c'est en reflechissant qu'on trouve les problemes. Ca tient aussi a la nature des bugs recherche -- les miens sont souvent des interactions subtiles ou une vision trop pres du code n'indique pas la nature reelle du probleme.

A la réflexion, tu as raison au moins à 50%. Mon expérience m'a plutôt amené à penser que 80% de bugs sont dus à des lacunes en tests unitaires, et donc on les trouves plus facilement avec le debugger. Mais là où je te rejoint, c'est que les bugs subtils (multi-thread, réseau, dynamique d'échange de messages windows ...) sont en général plus facilement diagnostiqués en analysant la dynamique d'ensemble avec des traces.