Discussion :

[Nicolas38]

Bonjour à tous,

je suis en train de développer un programme de simulation multiplateforme Mac/Linux, qui travaille sur du calcul flottant.
Il est essentiel que ce programme donne les mêmes résultats sur les différentes plateformes cible.

Je pensais que tout irait bien, compte tenu des normes IEEE sur les calculs flottant. Or, dans certains cas, des différences apparaissent au fur et à mesure des calculs. Il semblerait que cela soit le cas surtout lorsque je fais de nombreux tests (==, <=) sur les flottants dans la boucle de calcul.

Quelqu'un aurait-il une idée pour corriger ce BIG BIG problème, ou un lien sur le net (je n'ai rien trouvé moi même) ?

Merci !
Nico

Pour info :
- le code est élémentaire : tests conditionnels, additions, multiplications, divisions, c'est tout (pas de racine, logarithmes...).
- j'ai compilé sur Linux 2.4 avec gcc, sur mac OS X.3 avec gcc. Dans les deux cas sans optimisation.

[rolkA]

Salut.
Les différences ne sont-elles pas négligeables ?

[Nicolas38]

'lu,

Négligeables, euh, voyons... Deux réponses.

Tout d'abord, non, je ne peux pas me permettre de les négliger.
Puisqu'il s'agit d'un simulateur, elles vont s'amplifier avec le temps. Pour, au finish et après qqs heures ou jour de travail, donner des résultats totalement incomparables. Compte tenu du fait que les divers utilisateurs sur les diverses plateformes doivent travailler ensemble, échanger des données (des modèles, etc), ce n'est pas du tout "négligeable".

Ceci dit, OUI, ces erreurs sont négligeables, en ce sens qu'elles sont très petites. Le problème, c'est que leur cumul finit par foutre le boxon.

[dok3]

Bonjour à tous,
Je pensais que tout irait bien, compte tenu des normes IEEE sur les calculs flottant. Or, dans certains cas, des différences apparaissent au fur et à mesure des calculs. Il semblerait que cela soit le cas surtout lorsque je fais de nombreux tests (==, <=) sur les flottants dans la boucle de calcul.

tu les fait comment tes comparaison ?
ne jamais faire directement de comparaison impliquand une egalite entre des flottant ... toujours rajouter un epsilon.

soit dit en passant les resultats sur des flottant sont susceptible de changer entre differents couple compilateur/processeur .. c'est normal

[Gandalf]

'lu,

Négligeables, euh, voyons... Deux réponses.

Tout d'abord, non, je ne peux pas me permettre de les négliger.
Puisqu'il s'agit d'un simulateur, elles vont s'amplifier avec le temps. Pour, au finish et après qqs heures ou jour de travail, donner des résultats totalement incomparables. Compte tenu du fait que les divers utilisateurs sur les diverses plateformes doivent travailler ensemble, échanger des données (des modèles, etc), ce n'est pas du tout "négligeable".

Ceci dit, OUI, ces erreurs sont négligeables, en ce sens qu'elles sont très petites. Le problème, c'est que leur cumul finit par foutre le boxon.

C'est très embettant... cela remet vraiment en cause la qualité de ton simulateur. Si ta resolution mathematique n'est pas stable (ce que tu décris) alors il n'y a pas de raison que tu obtiennent une valeur valable...

Au contraire, si ta resolution est stable, peu importe les arrondis, tu convergera vers la meme solution...

Note on ne fait jamais de == entre flottants...

[rolkA]

Note on ne fait jamais de == entre flottants...

En d'autres termes, soit x et y deux flottants de type double, remplacer ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
if (x == y)
{
   //...
}

Par ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
if (fabs(x - y)  < std::numeric_limits<double>::epsilon())
{
   //...
}

Cependant, je doute que ces précisions résolvent le problème initial.

[FVIRTMAN]

tres étrange.

Cependant, je te dirais - sans etre sur bien sur que ça vienne de la - que les processeurs Mac et PC sont en Endian différents.
Je sais que ça pose probleme sitot que tu as passage de données d'un systeme a l'autre, ou alors castage violent de char* sur short* par exemple.
Ce codage joue peut etre au niveau des float, mais je suis étonné.

Vérifie si tu n'as pas de castages bourrins comme cela.
Ensuite, je confirme ce qu'on dit les autres : jamais de == sur des float ou double

[FVIRTMAN]

essaie, a tout hasard, de faire afficher les sizeof(double) et sizeof(float) sur les 2 systemes : peut etre qu'ils ne codent tout deux pas sur le meme nombre d'octets :
(tout comme "int" qui, a l'origine, était sur 2 octets)
cela pourrait éventuellement venir de la...

Peut etre que les mac stockent les double sous 4 octets comme des float, alors que le PC sur 8... ça jouerait...

[Gandalf]

Note on ne fait jamais de == entre flottants...

En d'autres termes, soit x et y deux flottants de type double, remplacer ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
if (x == y)
{
   //...
}

Par ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
if (fabs(x - y)  < std::numeric_limits<double>::epsilon())
{
   //...
}

Cependant, je doute que ces précisions résolvent le problème initial.

Souvent on prefere une forme proportionnelle, par exemple :
1.0-min(|x|,|y|)/max(|x|,|y|) < epsilon && x*y > 0

mais c'est à voir en fonction des cas (attention au division par zero)

Quand au problème initial, ce n'est pas un problème, c'est ignorer volontairement l'erreur d'arrondi qui est associée aux types folttant et qui depend entre autre du type de proc et de la taille des registres flottants...

[Nicolas38]

soit dit en passant les resultats sur des flottant sont susceptible de changer entre differents couple compilateur/processeur .. c'est normal

Oui, c'est ce que j'ai compris avec quelques lectures depuis.
Mais il reste que les normes IEEE devraient (quand on les lit !) permettre d'éviter cela. Et je suis assez certain que ce doit être faisable, compte tenu de l'importance de la chose !

Auriez vous une piste pour ça : document à lire, article qui y fait référence, options de compilation qui "forcent" le respect d'une norme, etc. ?


Pour ce qui est des comparaisons, je fais ça avec des < ou >, et parfois avec des <= et >= .
Pour ce qui est des "epsilon", ma fois, j'étais au courant, mais en même temps le fichier limits.h définit ses propres "epsilon"... et oui, je l'avoue, le code dont je parle est une bibliothèque C, pas C++ .

A moins que C++ soit blindé face à ces problèmes (ce dont je doute, cf le "quote" de dok3 ci dessus), et que le HIC provienne du code en C - de sorte que je doive reposer ces questions sur le forum C ?

[dok3]

pour < et > pas de probleme mais <= et >= implique un test d'egalite ... donc besoin d'un epsilon

la norme IEEE c'est beau mais la realite c'est mieux, la precision des calculs depends du couple compilateur/processeur, il faut faire avec.

Si une solution miracle existe je ne la connais pas, mais personne ne peux tout savoir, surtout pas moi ... alors ... peut etre

[JolyLoic]

Si tes deux processeurs faisaient la même chose, on pourrait en effet s'attendre à avoir les même résultats. Le problème, AMA, est que comme tu utilises des compilateurs différents, ils optimisent différemment, et donc les deux processeurs ne font pas les mêmes calculs. Pour vérifier, mon hypothèse, il pourrait être intéressant de comparer les résultats sans aucune optimisation, mais comme les processeurs modernes optimisent à la volée, je ne vois pas vraiment comment faire.

[rolkA]

Pourtant il a dit:

- j'ai compilé sur Linux 2.4 avec gcc, sur mac OS X.3 avec gcc. Dans les deux cas sans optimisation.

On pourrait éventuellement comparer le code assembleur généré ? Les machines n'étant pas les mêmes çà me parait tendu

[SKZ81]

1.0-min(|x|,|y|)/max(|x|,|y|) < epsilon && x*y > 0
mais c'est à voir en fonction des cas (attention au division par zero)

Suffit juste d'inverser les conditions (puisque si x*y>0, alors x!=0 et y!=0), et profiter de la short-circuit evaluation...
Mais à la reflexion ton test me parraît étrange : et si x=y=0.0 ?

Si les systèmes s'échangent des données, ne peut tu pas les synchroniser périodiquement ? (Ca implique que le plus rapide attende l'autre, je sais...)

Une autre solution, c'est la virugle fixe : tu remplace tes flottants par une classe qui possède un int pour la partie entière et un int pour la partie décimale. Dans certains cas ça accèlère même les calculs !
De quelle précision à tu exactement besoin en partie décimale ?

[Higestromm]

Je me demande si il ne faudrais pas coder tes operateurs en assembleur afin d'etre certain que les calculs soient fait de la meme maniere...

Dailleur je me demande si on insere du code assembleur dans un code c++ si le compilo vas passer dessus et l'optimiser ou pas ?

[k'n1]

dans pas mal de cas, j'ai prefere utiliser des long int plutot que des float, en multipliant simplement toutes les valeurs par la precision minimal de tes float.... genre, si tes float vont jusqu'a 10E-8, tu multiplie tout par 10E8 et tu utilise ca dans ton programme...

bon ok c'est pas tres propre, mais dans mon cas j'utilisais ca pour des appli plutot monetaires, ou on m'a gentiment explique que mettre des sous en float etait une heresie totale ^_^ (avec les float tu arrive toujours a avoir un 0.00000001 qui reste quelque part, au bout d un moment ca fait un petit trou dans la caisse... et si chaque programme le fait, ca devient du detournement de fond involontaire ) ... bref tout ca pour dire que je multipliait donc par 10E2 pour eviter ces problemes, voir 10E4 je crois dans le cas d'appli plus pointues (bourse etc...)

a voir selon la precision de ton simulateur, mais clairement les float c'est vraiment lourd a gerer ^_^ (et encore maintenant ca va a peu pres, a l'epoque des K6 il faisait pas bon de faire tourner une appli avec des float sur un amd ^_^ )

PS: lol l'etudiant qui va chercher ses souvenir de quand j'etais jeune... bientot la retraite !!