Discussion :

[Bousk]

Au regard de ce qu'avance Medinoc, ton problème est certainement plus grave que ta focalisation sur ces sorties...

[3aychoucha]

Au regard de ce qu'avance Medinoc, ton problème est certainement plus grave que ta focalisation sur ces sorties...

c'est quoi ce problème? ce qui m’intéresse c'est le résultat final car c'est là que je vois la différence
Je suis pas experte c'est pourquoi je cherche l'aide

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?

oui tu as raison, c'est le modèle de virgule flottante qui est différent

[LittleWhite]

c'est quoi ce problème? ce qui m’intéresse c'est le résultat final car c'est là que je vois la différence

Sauf que avoir un résultat juste, avec un code, disons, mal écrit, cela s'appelle de la chance (et moi, j'appelle ça aussi, bâclé son travail et faire un truc qui ne sera pas du tout utilisable dans le futur, donc du gâchis).
Après, c'est à vous de voir.

Lorsque je vois des différences, rien que sur cette ligne (ou même la première) :

radius 0.0285115

J'ai peur.
Donc, vous reprenez de l'itération une (sans même en faire 60), et vous voyez si les résultat son identique. Ensuite, vous utilisez soit un débogueur, soit des printf/cout et vous déboguez pour voir où cela diverge.

[3aychoucha]

j'avoue je suis pas experte et je demande votre aide: je ne trouve pas exactement l'erreur
Bien sure je veux corriger mon code (notamment bien écrire mon programme) et par conséquent j'aurai le bon résultat
Si j'insiste sur le bon résultat c'est que j'insiste à corriger l'erreur et donc je me suis redirigée vers vous
Merci

[bacelar]

Déjà, avant de faire les Nosferatu entre 32bits et 64bits, commences par avoir les mêmes résultats en Debug et en Release (et un code fiable, ça mange pas de pain).

[3aychoucha]

Bonjour,
je vous remercie pour vos réponces, mis jusqu'à maintenant vous ne m'avez donné aucune piste pour modifier ou corriger mon code, d'où je dois commencer, qu'est ce que je dois faire ...

[Médinoc]

J'ai donné une piste: Plus de rigueur dans les classes utilitaires, si tu tiens à utiliser des classes 1-indexées. Éviter d'exposer publiquement des méthodes que tu n'utilises pas depuis l'extérieur. Plus de vérifications (des assertions par exemple)...

Et bien sûr, faire tes tests en /fp:strict dans tous les cas.

[Danny-k]

J'ai regardé très rapidement ton code, et déjà une chose m'a interpellé, c'est ta fonction getElement dans GMatrix :

Code :

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

1
2
3
inline const double& getElement (  int lineIndex,   int columnIndex) const{
	return _dataMatrix[(lineIndex-1)*_nbColumns + (columnIndex-1)];
}

Très étrange de mettre les index moins 1, donc je me suis dit c'est qu'il y a de fortes chances que tu commences tes a indices a 1 dans tes parcours, et en effet c'est bien le cas, dans toutes les utilisations de cette fonction :

Code :

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

1
2
for(int i = 1; i<=_nbColumns; i++)
     res(i) = this->getElement(lineIndex,i);

Cependant, quand tu alloue _dataMatrix dans allocGMatrix :

Code :

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

1
2
3
4
_dataMatrix = new double[_nbLines*_nbColumns];
	for (  int i = 0; i < _nbLines; ++i)
		for (  int j = 0; j < _nbColumns; j++)
			_dataMatrix[i*_nbColumns+j] = 0;

Les indices sont à 0. Ton code fait tout simplement un buffer overflow, vu qu'à un moment tu vas écrire une case plus loin que la taille du tableau alloué.

Typiquement :

Code :

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

1
2
double * d = new double[2];
d[2] = M_PI;

Est le genre de choses qu'il ne faut pas du tout faire.

Donc voilà pas très étonnant tes résultats différents.

Ce que je te préconise de faire :
- est de remplacer ton pointeur de double dans ta classe (_dataMatrix), et d'utiliser un std::vector, vu que tu codes sous Visual 2012, en débug, il t'aurait lancer une exception sur le dépassement de ton tableau avec l'utilisation de l'opérateur [] (pas en release cependant, cela n'est fait qu'avec la fonction at()).
-de commencer toutes tes boucles à l'indice 0 au lieu de 1, ce qui fait qu'il faut que tu changes ta fonction getElement en conséquences.
-vu que tu as fais le choix de travailler sur une dimension (ce qui est très bien), il faut que tu gardes à l'esprit que ta fonction getElement fait un parcours en row major dans l'état actuel des choses, donc il faut que tes parcours prennent bien en compte ce fait afin de ne pas avoir de surprise.

Je te laisse lire ce lien sur le Major Order

[3aychoucha]

Merci Danny-k et Médinoc, je vais remplacer tout en vecteur et je re vers vous
Médinoc, il y a des fonctions publics car elles sont utilisées dans d'autres codes

[3aychoucha]

Problème résolu,
Merci à vous tous,
Et un très grand merci à Danny-k

le fait de remettre tous les indices à 0 a résolu mon probleme
Merci encore une fois

[3aychoucha]

Bonjour,
Je suis de retour, j'ai cru que mon probleme est résolu mais j'avais tord,
J'ai utilisé std::vector au lieu de double * dans mes Gmatrix et Gvector, j'obtient le même résultat en release et en debug mais pas en 32 et 64 bits.
la modification de l'option strict et précise ne change pas le résultat
Avez vous une idée sur ce qui ce passe svp?

[bacelar]

Avez vous une idée sur ce qui ce passe svp?

Fournis un code minimal qui reproduit le problème.

[3aychoucha]

Fournis un code minimal qui reproduit le problème.

Compute - Vector.zip

NB: J'ai modifié que les index des fonctions utilisées dans les calculs
Merci

[Danny-k]

Dans ta première version, tu avais fait le choix d'utiliser un tableau à une dimension

Code :

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

double * _dataMatrix

Et là tu fais le choix d'utiliser un tableau à 2 dimensions

Code :

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

vector<vector<double>> _dataMatrix

C'est dommage, tu n'avais juste qu'à remplacer ton pointeur par un vecteur sans rien changer.

Soit dit en passant le problème n'est pas là et je vois que tu n'as pas suivi complètement mes conseils, puisque tu continue toujours à commencer tes indices à 1 dans GMatrix et GVector. En gros partout où tu fais :

Code :

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

for(int i = 1; i <= size; ++i)

change par :

Code :

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

for(int i = 0; i < size; ++i)

Ta fonction getElement :

Code :

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

1
2
3
inline double& getElement (  int lineIndex,   int columnIndex){
		return _dataMatrix[(lineIndex-1)][(columnIndex-1)];
	}

Doit devenir :

Code :

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

1
2
3
inline double& getElement (  int lineIndex,   int columnIndex){
		return _dataMatrix[lineIndex][columnIndex];
	}

Idem pour setElement.

De plus passe tes paramètres de types primitifs, par valeur plutôt que const reference :

Code :

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

void setElement (int lineIndex, int columnIndex, double value);

Ensuite, la fonction allocGMatrix, n'a pas grande utilité, tu peux déplacer le corps de cette fonction directement dans le constructeur et l'opérateur d'affectation, et initialiser ton vector par liste d'initialisation dans le constructeur paramétré, ça sera plus performant. Rien ne sert de clear dans le constructeur, vu que le vector par défaut à une taille de 0.

Le problème persiste, car dans cette fonction tu construit un vector avec _nbLines et _nbColumns, mais tu parcours jusqu'à _nbLines et _nbColumns compris, d'où les problèmes persistant.

Là j'ai parlé uniquement que de GMatrix, mais c'est la même chose dans GVector, l'idée quand on développe une bibliothèque matricielle, avant de passer aux opérations avancées, telles que l'inversion, multiplication, etc. C'est d'abord de tester l'intégrité de ses valeurs, sur un jeu de données assez petit, tester les bornes (typiquement là les buffer overflow), et de tester les fonctions élementaires comme les accès (tes fonctions getElement et setElement ; qui soi dit-en passant gagnerait peut-être en lisibilité avec une surcharge de l'opérateur() plutôt que d'être autant verbeux avec des fonctions get et set.)

[3aychoucha]

Merci Dannu-k pour votre réponse,

Le problème persiste, car dans cette fonction tu construit un vector avec _nbLines et _nbColumns, mais tu parcours jusqu'à _nbLines et _nbColumns compris, d'où les problèmes persistant.

J'ai noté que je n'ai pas modifié tout le code, j'ai modifié juste les fonctions et les opérateurs utilisés dans compute, concernant les indices qui commencent par 1 c'est parce que il y a un -1 dans set et get donc ça devient 0, sinon le vector aurait lever une assertion failed,
donc normalement il y aura pas de problème de commencer par 1 et faire un -1, ça revient au même de commencé par 0, et _nbLines, _nbColumns ne sont pas atteint, sinn avec vector il aura l'exception

[dragonjoker59]

Ben oui, mais si tu ne corriges pas le problème partout où il apparait, ça ne peut pas aller non plus...

[3aychoucha]

Ben oui, mais si tu ne corriges pas le problème partout où il apparait, ça ne peut pas aller non plus...

Si je l'ai corrigé là où il faut, si tu exécute tu peux remarquer qu'il n'y a pas de bug.

[Danny-k]

Le problème c'est qu'il n'y a absolument aucune homogénéité dans ton code, à certains endroits, tu utilises des indices commençant a 0, et d'autres à 1.
Ce n'est pas parceque visual ne lève pas une exception que tu prends la bonne valeur.

Ce que je te conseillerais c'est de refactorer ton code pour n'avoir que des indices à 0 partout, tu peux penser que c'est une perte de temps, mais au final tu auras un code homogène plus facilement debuggable, de plus c'est une norme en informatique de toujours commencer a 0, je ne connais aucune bibliothèque matricielle digne de ce nom qui travaille sur des indices commençant à 1.

[JolyLoic]

Je connais juste Matlab qui commence à 1 pour ses matrices (et VBA qui permet de choisir), et c'est vraiment casse bonbons

[Bousk]

En LUA les indices commencent à 1 aussi par convention. (même s'il est possible de faire à peu près n'importe quoi et continuer à utiliser le 0 par défaut, mais ça te prive de fonctions de base de parcours etc de mémoire)