Discussion :

[3aychoucha]

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?

[bacelar]

Il a donc trouvé 0 erreurs, cela ne veut pas dire qu'il y a 0 erreurs.
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.

[Médinoc]

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.

[3aychoucha]

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
en fait pour mon code il s'agit d'opérations simples

Code :

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

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



Vos avis svp?

Merci

[bacelar]

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.
La solution de @Médinoc donne quoi ?

[3aychoucha]

radius2 est initialisée

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

[bacelar]

Projet minimal permettant de refaire ces constatations SVP.

[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.

[Bousk]

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.

[3aychoucha]

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

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.
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!

[camboui]

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 :

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

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

Code :

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

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 :

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

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.

[Bousk]

ç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.

[3aychoucha]

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

[Bktero]

Bonjour,

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

[JolyLoic]

Ç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>

[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 :

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

Defined -2

Debug Win32 sans débogueur: Crash violnt.

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 violnt.


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

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

EDIT: ;-°

[Bousk]

Crash violant.

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

[Médinoc]

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...

[3aychoucha]

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

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

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

en 64 bits Debug

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

en 64 bits Release

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?

[dragonjoker59]

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?