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.