Discussion :

[libredr]

Bonjour,

J'ai un etrange probleme quand je convertis des nombres d'un string vers double.

J'ai un fichier avec des nombres en ligne:

Code :

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

5.6 0 0.205867 1.0809 7.22644 0.373206 -5.84675e-317 1.99995 0.00433641 1.45331e-45

Je veux inserer ces nombres sous forme de doubles dans un vecteur de doubles.
Mon probleme apparait avec de tres petites valeurs (inferieures a 1e-310).

Avec ce code:

Code :

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

1
2
3
4
5
vector<double> vals;
double x;
while (stream >> x) {
      vals.push_back(x);
}

le vecteur vals est tronque : 5.6 0 0.205867 1.0809 7.22644 0.373206
-5.84675e-317 est elimine et je sors de la boucle.

C'est pareil en utilisant la STL:

Code :

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

copy(istream_iterator<double>(stream), istream_iterator<double>(), back_inserter(linevals) );

En revanche cette methode fonctionne:

Code :

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

1
2
3
4
5
6
7
vector<double> vals;
double x;
string st;
while (stream >> st) {
      x = atof(st.c_str());
      vals.push_back(x);
}

Pourquoi seul atof est capabble de convertir des valeurs tres petites?

Merci d'avance.

[libredr]

Note: j'utilise gcc/g++ 4.2.2 sous Unix (IBM AIX).

Note2: il semble que les nombres < a 1e-310 sont denormalises, ca vient peut-etre de la. Maintenant pourquoi les nombres denormalises sont bien traites, je ne sais pas.

[BoudBoulMan]

Peut-�tre est-ce le caract�re 'e' qui n'est pas reconnu?

[Sylvain Togni]

Le probl�me provient surement du fait que la valeur est inf�rieur � DBL_MIN (�gal � 2.2250738585072014e-308 le plus souvent). Par contre je ne sais pas si la norme sp�cifie si l'extraction doit �chouer, si l'extraction doit donner 0.0 ou si c'est un comportement ind�fini.

[Emmanuel Deloget]

Sous toutes r�serves...

Le probl�me provient surement du fait que la valeur est inf�rieur � DBL_MIN (�gal � 2.2250738585072014e-308 le plus souvent). Par contre je ne sais pas si la norme sp�cifie si l'extraction doit �chouer, si l'extraction doit donner 0.0 ou si c'est un comportement ind�fini.

Le comportement est vaguement d�fini. Attention, c'est un peu compliqu� :
1) C'est celui de scanf "%el", c'est � dire - par ricochet - � celui de strtod().

2) La norme C99 dit alors :

The functions return the converted value, if any. If no conversion could be performed, zero is returned. If the correct value is outside the range of representable values, plus or minus HUGE_VAL, HUGE_VALF, or HUGE_VALL is returned (according to the return type and sign of the value), and the value of the macro ERANGE is stored in errno. If the result underflows (7.12.1), the functions return a value whose magnitude is no greater than the smallest normalized positive number in the return type; whether errno acquires the value ERANGE is implementation-defined.

3) Selon l'impl�mentation C++ utilis�e, cela se traduira peut-�tre par la mise � true du failbit du stream - si errno est mis � ERANGE et que le stream r�cup�re la valeur de errno. Hors l'expression "while (stream >> x) { }" est �quivalente � "while (stream >> x, !stream.fail()) { }" ce qui provoque la sortie de ta boucle.

4) dans le dernier exemple, puisque atof() est un alias de strtod(), tu h�rite du m�me comportement. Mais puisque tu ne v�rifie pas errno, ta boucle fonctionne.

Enfin bref - c'est un peu compliqu� (mais l'id�e est que tu sors de ta boucle parce qu'il y a une erreur quelconque, que tu ne reproduit pas dans l'autre boucle parce que tu n'utilises pas les m�me m�canismes).

[libredr]

Merci beaucoup pour ces reponses et commentaires. En fait, j'ai verifie le programme sous Linux avec la meme version de g++, et cela marche! Le probleme est specifique a la plateforme AIX. J'ai rapporte l'observation sur le bugzilla de GCC, en attendant de voir si c'est bien un bug.