Différence de résultat entre x86 et x64

Bonsoir à tous,
l'analyse avec dr memory m'a donné 0 erreurs, il ne s'agit donc pas d'une erreur mémoire,
en fait puisque je fais des multiplications matricielles sur différentes itérations, l'erreur état minime puis s'accumule jusqu'à ce quelle devienne grande
vos avis svp?

Il a donc trouvé 0 erreurs, cela ne veut pas dire qu'il y a 0 erreurs. :aie:
Vous avez donc un problème de stabilité numérique, comme toujours avec des nombres à virgule flottantes, quand on y va la fleur au fusil.
Et un problème de stabilité numérique, c'est un bug, et un bug que "dr memory" n'est pas près de détecté, c'est pas son taf.

Par défaut, Visual Studio est en mode Précis et non en mode Strict.
Tu peux essayer de compiler ton projet en mode Strict, et là ça ne devrait pas varier.

C'est ce que je disait dès le début, il s'agit d'un problème avec les doubles, me je ne sais pas quoi exactement :mrgreen:
en fait pour mon code il s'agit d'opérations simples

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

r = sqrt(x*x+y*y); n1 = x/r; n2 = y/r; er = r-radius;   r2 = sqrt(er*er+z*z); ; n21 = er/r2; n22 = z/r2; xsi = r2 - radius2;   sxsi += (xsi*xsi);   myfile << nb_interation << "\t" << j << "\t" << r << "\t" << er << "\t" << r2 << "\t" << xsi << "\t" << sxsi << endl;

---

ce traitement s'effectue dans deux boucles imbriquées

J'ai enregistré les étapes de calcul dans un fichier et j'ai comparé les résultats, les différences commencent minimes, mais après ça change complètement

Pièce jointe 225691Pièce jointe 225692

Vos avis svp?

Merci

Citation:

---

il s'agit d'opérations simples

---

Des racines carrées, des divisions avec des opérandes potentiellement pas du même ordre de grandeur, somme cumulative d'un carré d'un résultat intermédiaire (sans compter que "radius2", on sait pas s'il est initialisé), vous avez une définition du simple d'un point de vue stabilité numérique assez lâche. :weird:
La solution de @Médinoc donne quoi ?

radius2 est initialisée

La solution de Médinoc n'a rien changée

Projet minimal permettant de refaire ces constatations SVP.

J'ajoute qu'il faut se méfier de l'affichage.
Il n'est pas complètement exclu que ce soit uniquement l'affichage qui diffère.

Exact, c'est pour ça qu'une bonne comparaison se fait sur le binaire et non sur un affichage en digits fait par on ne sait quelle méthode qui peut se permettre on ne sait quels arrondis pour y parvenir.

Citation:

---

Envoyé par ternel

J'ajoute qu'il faut se méfier de l'affichage.
Il n'est pas complètement exclu que ce soit uniquement l'affichage qui diffère.

---

Non, ce n'est pas une histoire d'affichage parce que à la fin du calcul la différence devienne grande

Citation:

---

Envoyé par bacelar

Des racines carrées, des divisions avec des opérandes potentiellement pas du même ordre de grandeur, somme cumulative d'un carré d'un résultat intermédiaire (sans compter que "radius2", on sait pas s'il est initialisé), vous avez une définition du simple d'un point de vue stabilité numérique assez lâche. :weird:
La solution de @Médinoc donne quoi ?

---

Et alors? ça explique la grande différence des résultats en 64 et en 32 bits? Normalement un traitement doit être le même quelque soit la plateforme!

Oui, tu as raison. Il ne devrait pas y avoir de différence.
Et puisqu'il y en a quand même une, c'est qu'il y a une erreur dans ton code et tu devrais la trouver.

On peut juste t'orienter vers des pistes de réflexion (à moins que tu nous fournisses un code minimal, comme demander par @bacelar, afin que l'on puisse reproduire les différences que tu observes).

Pour la petite histoire, j'ai moi-même récemment modifié un code qui fonctionnait bien en 32 et en 64 bits avant modification.
Avant:

Code:

---

1 2 3 4

inline int compare(unsigned int l, unsigned int r) { return int(l - r); }

---

Après, le résultat n'est plus celui espéré en 64 bits :aie:

Code:

---

1 2 3 4

inline intptr_t compare(unsigned int l, unsigned int r) { return intptr_t(l - r); }

---

En 64bits, sachant que sous windows un unsigned int reste en 32bits, le résultat sera toujours >0.
Je l'ai corrigé comme ceci (en généralisant au passage):

Code:

---

1 2 3 4 5 6 7

template<typename T> constexpr std::enable_if_t< std::is_integral<T>::value && (sizeof(T) <= sizeof(intptr_t)), intptr_t> compare(T l, T r) noexcept { return intptr_t(std::make_signed_t<T>(l - r)); }

---

En bref, vérifie bien tous les cast éventuels, implicites ou explicites, en plus des autres pistes déjà suggérées.

Citation:

---

Envoyé par 3aychoucha

ça explique la grande différence des résultats

---

Oui parce qu'à chaque opération des arrondis sont effectués. Plus d'opérations il y a, plus d'erreurs il y a. C'est la surenchère à la violence dès que le moindre bit diffère.

Après un retard qui est dû à une panne technique, je suis de retour :aie:
J'ai mis une version du projet sur le quel j'ai travaillé
Je ne trouve ps encore la source du problème :(Pièce jointe 226314

Bonjour,

La solution ne compile pas sur ma machine (Windows 7 64 bits, VS 2013) :(

Pièce jointe 226318

Ça ressemble hélas un grand classique windows... :(
Défini la macro NOMINMAX afin d'éviter que l'inclusion de windows.h ne vienne foutre la grouille dans le programme.

Si ce n'est pas ça, peut-être manque-t-il juste un #include <algorithm>

C'est un projet VS2012.
J'ai testé avec un Sevent 64bits, VS2012 Express.

Résultats :
Debug Win32 via débogueur: Une Exception ligne 249 de GSolve.cpp. C'est dans un constructeur.
-> L'objet est "Invalide".
Sortie du programme :

Citation:

---

radius2 -1.#INF
radius -1.#IND
ItÚration 0
radius2 1.#INF
radius -1.#IND

Defined -2

---

Debug Win32 sans débogueur: Crash viol:aie:nt.

Release Win32 via débogueur: Même exception quand Debug Win32, puis d'autre en boucles, jusqu'à une sortie via GPF en boucle.
Release Win32 sans débogueur: Crash viol:aie:nt.


Debug x64 via débogueur: même chose que Win32
Debug x64 sans débogueur: Crash viol:aie:nt.

Release x64 via débogueur: Même exception quand Debug Win32.
Release x64 sans débogueur: Crash viol:aie:nt.

EDIT: :aie: ;-°

Citation:

---

Envoyé par bacelar

Crash violant.

---

je sais pas si c'est une erreur de frappe, mais ça doit faire mal à l'ordinateur. :mouarf:

J'ai tenté de jeter un œil au code source, rien que dans la classe GVector il y a des trucs bien suspects, à commencer par le fait qu'il soit publiquement 1-indexé, mais aussi des horreurs comme le desallocGVector() qui est public et ne remet pas le pointeur à zéro après désallocation, le getVector() également public qui ne vérifie pas que le vecteur en entrée est suffisamment grand, l'opérateur = qui n'utilise pas le copy-and-swap (pas plus que les autres opérateurs assignants), l'opérateur ! qui non seulement est défini, mais duplique le code de getNorm() au lieu de l'appeler, et la gestion bizarre de la division par zéro.

J'ai peur de m'aventurer dans les autres fichiers...

Edit: Oh, et pour la rigolade, le header inclut le vrai <vector> sans raison...

Citation:

---

Envoyé par bacelar

C'est un projet VS2012.
J'ai testé avec un Sevent 64bits, VS2012 Express.

Résultats :
Debug Win32 via débogueur: Une Exception ligne 249 de GSolve.cpp. C'est dans un constructeur.
-> L'objet est "Invalide".
Sortie du programme :

---

Je confirme, c'est un projet VS 2012
c'est bizarre!!!, je n'aurai pas ces exceptions, mais je trouve des résultats différents en 32 et en 64 bits

en 32 bits Debug

Citation:

---

Itération 60
radius2 12.0686
radius 0.974234
_best_score 33.951
_best_vector
-0.571505
0.820599
-0.000649084

---

en 32 bits Release

Citation:

---

ItÚration 60
radius2 12.4158
radius 0.0285115
_best_score 574361
_best_vector
-0.468735
-0.269469
-0.841233

---

en 64 bits Debug

Citation:

---

ItÚration 60
radius2 12.426
radius 0.0282537
_best_score 605926
_best_vector
0.473728
0.876396
0.0866695

---

en 64 bits Release

Citation:

---

ItÚration 60
radius2 12.426
radius 0.0282537
_best_score 605926
_best_vector
0.473728
0.876396
0.0866695

---

Le résultat est le même pour l'exécution 64 release ou debug, mais en 32 bits c'est différent
Une explication svp?

C'est quand même étrange que tu aies des différences de résultat entre debug et release, en 32 bits, ça pue, ça.
Tu n'aurais pas des différences d'options de compilation, entre les 2 modes?