Discussion :

[BioKore]

Bonjour à tous,

Ces quelques derniers jours, j'ai dépoussiéré un projet réalisé il y a 2 ou 3 ans sous linux (dont on retrouvera des vestiges dans différents posts sur ce forum), nécessitant la lecture de fichiers de type *.idx.
Sans grande surprises, à la lecture du code réalisé à l'époque, ce dernier nécessite une totale refactorisation compte tenu de ma prise de maturité dans le langage depuis (merci au forum !!!).

Je m'y plonge donc, et, cette fois-ci par contre, grande surprise ! La sortie fournie par l'outil ne correspond pas à celle attendue (censée être finalement la même que le code initial).

Je retourne donc le code dans tous les sens, essaie d'autres méthodes, m'assure plutôt 10 fois qu'une que l'algorithme est viable etc... Bref, le code qui devais être une mise au propre devient alors un code de test... Rien y fait. En 3 jours de recherche, même le code initial qui me servait de base recrache toujours la même chose : une sortie tronquée (pas fausse, tronquée ; une partie des infos semble corrompue) par rapport à ce qui est attendu.
Je me dit, "ok, j'utilise GCC en powershell, peut-être que le sujet vient du compilo". J'installe donc Code::Blocks (ayant formaté il y a peu, avec windows on en prends l'habitude) et là, le résultat est exactement le même (normal ; MINGW = GCC).
Ayant eu des soucis lors de l'installation de code-blocks (pas sure du compilateur utilisé) et n'arrivant pas à le désinstaller complètement, je formate donc (encore... Pauvre SSD....) et test à nouveau avec code-blocks sur une installation brute (+ mises à jour windows et Drivers). Résultat. Toujours le bug.

Je réfléchis donc encore un peu : "le code de base fonctionnait à l'époque, moche, lent, absolument pas optimisé, mais les sorties étaient correctes et faisaient le taff. Je vais tester mon nouveau code (finalement à refaire quand même suite aux modifications vues précédemment mais bon) sur mon ancienne machine". Et là, illumination. Tout fonctionne nickel.

Verdict surprenant : le bug que j'ai, ne faisant appel qu'à des fonctions de base de la STL, est erratique sous Windows et fonctionne très bien sous Débian !! Pourquoi ???

Pour info, le code ne fait que charger 60'000 "images" de 28 pix * 28 pix au format IDX dans un vecteur lui même encapsulé dans une structure, et m'affiche à la demande l'image n° X ou Y. Je ne fais donc qu'intervenir des for, std::vector et std::fstream.

Le code complet étant suffisamment long pour n'avoir que peu d'intérêt ici, je ne mettrais que les parties "intéressantes". Bien entendu, si vous souhaitez en voir l'intégralité, il suffit de demander (finalement, on en est pas loin):

La déclaration de la classe principale (et des structures sous-jacentes) :

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
#pragma once
 
#include <cstdlib>
#include <string>
#include <vector>
#include <iostream>
#include <fstream>
 
 
struct LabelSet {
	size_t magic;
	size_t size;
	std::vector<unsigned char> labels;
};
 
struct PictureSet {
	size_t magic;
	size_t size;
	size_t rowDim;
	size_t colDim;
	//std::vector<std::vector<std::vector<unsigned char> > > pictures;
	std::vector<std::vector<unsigned char> > pictures;
};
 
enum TYPE_SET { IDX_LABEL, IDX_PICTURE };
 
class IDX_Reader {
private:
	LabelSet mLabel;
	PictureSet mPicture;
 
public:
	IDX_Reader();
 
	void load(TYPE_SET const & SET, std::string const & path);
	void loadLabel(std::fstream & labelFile);
	void loadPicture(std::fstream & pictureFile);
 
	void read(size_t const id);
 
};
 
 
// EOF

Rien de bien méchant jusque là...
Les déclarations des deux principales fonctions utilisées (en tout cas celles que j'estime pouvant être à l'origine du bug) :

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
void IDX_Reader::loadPicture(std::fstream & pictureFile) {
	mPicture.magic = (pictureFile.get() << 24) | (pictureFile.get() << 16) | (pictureFile.get() << 8) | pictureFile.get();
	mPicture.size = (pictureFile.get() << 24) | (pictureFile.get() << 16) | (pictureFile.get() << 8) | pictureFile.get();
	mPicture.rowDim = (pictureFile.get() << 24) | (pictureFile.get() << 16) | (pictureFile.get() << 8) | pictureFile.get();
	mPicture.colDim = (pictureFile.get() << 24) | (pictureFile.get() << 16) | (pictureFile.get() << 8) | pictureFile.get();
 
	//case of 2D vector
	mPicture.pictures.clear();
	mPicture.pictures.resize(mPicture.size);
	for(auto & pic:mPicture.pictures) {
		pic.resize(mPicture.rowDim * mPicture.colDim, 0);
		for(auto & pix:pic) {
			pix = static_cast<unsigned char>(pictureFile.get());
		}
	}
 
	// case of 3D vector
	/*mPicture.pictures.clear();
	mPicture.pictures.resize(mPicture.size);
	for(auto & pic:mPicture.pictures) {
		pic.resize(mPicture.rowDim);
		for(auto & row:pic) {
			row.resize(mPicture.colDim, 0);
			for(auto & col:row) {
				col = static_cast<unsigned char>(pictureFile.get());
			}
		}
	}*/
 
}
 
 
void IDX_Reader::read(size_t const id) {
	std::cout << "Printing picture of index " << id << '\n';
	std::cout << "Label : " << static_cast<unsigned short>(mLabel.labels[id]) << '\n';
 
	// case of 2D vector
	for(size_t r{0}; r != mPicture.rowDim; ++r) {
		for(size_t c{0}; c != mPicture.colDim; ++c) {
			if(mPicture.pictures[id][c + (r * mPicture.colDim)] > 0) {
				std::cout << 'x';
			} else {
				std::cout << ' ';
			}
		}
		std::cout << '\n';
	}
 
	// case of 3D vector
	/*for(auto & row:mPicture.pictures[id]) {
		for(auto & col:row) {
			if(col > 0) {
				std::cout << 'x';
			} else {
				std::cout << ' ';
			}
		}
		std::cout << '\n';
	}*/
 
 
}

Et, je mettrais bien une extraction des sorties attendues (fournies par la fonction IDX_Reader::read(size_t const id)) mais je dois encore ré-installer virtual-box et / ou trouver une manière de reproduire une version buguée et une non buguée sur la même machine...

Mais globalement, les images (en niveau de gris [0 - 255]) doivent apparaitre à l'écran en mode console (voir algo de la fonction IDX_Reader::read(size_t const id)). Mais sous windows, à partir de la moitié de l'image 5, l'affichage apparait comme si les pictureFile.get() n'étaient pas faits (toutes les valeurs sont à 0, 255 si non défini dans le resize).


Dernière précision, sur mes deux machines, unsigned char = 8bits // int = 32 bits, les processeurs sont intel (des core I-7 86-64 sur les deux même si pas de même génération). Rappel : Intel = Litle Endian




Une idée de comment compiler ça sous windows ? A mon avis, au prochain format, je repasse sous Buster + XFCE4....


Merci d'avance !

[jo_link_noir]

L'une des premières choses que je fais est de sortir les analyseurs dynamiques: asan et compagnie pour le compilateur (-fsanitize=address,undefined) et valgrind.

En plus d'activer le debug de libstdc++ (-D_GLIBCXX_DEBUG (ou -D_GLIBCXX_ASSERTIONS pour avoir la compatibilité de l'abi)) et libc++ (-D_LIBCPP_DEBUG=1 qui possède un bug avec les versions fournit avant clang-8).

La majorité du temps, il n'y a pas à chercher plus loin. Le problème apparaît, il ne reste qu'à comprendre son cheminement.

[BioKore]

Que des choses que je n'ai jamais fait !

Je vais essayer de comprendre comment donner toutes ces commandes à manger à Code::Blocks (je n'ai pas re-install GCC pour powershell, mais ce n'est finalement peut être rien d'autre que MingW finalement ?).
Je test tout ça et je fais mon retour.

Merci pour les tips !

[koala01]

Salut,

Déjà, juste un truc :

Si, pour la facilité, tu créais une fonction de IDX_reader capable d'extraire des entiers de type int, sous une forme proche de

Code :

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

1
2
3
4
5
6
7
8
int extractInteger(std::fstream & ifs){
    int temp;
    temp| ifs.get()<<24;
    temp | ifs.get()<<16;
    temp | ifs.get() <<8;
    temp | ifs.get() <<0;
    return temp;
}

Cela te permettrait déjà de simplifier le code de fonction loadPicture sous une forme proche de

Code :

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

1
2
3
4
5
void IDX_Reader::loadPicture(std::fstream & pictureFile) {
    mPicture.magic =extractInteger(pictureFile);
    mPicture.size = extractInteger(pictureFile);
    mPicture.rowDim = extractInteger(pictureFile);
    mPicture.colDim = extractInteger(pictureFile);

De même, au lieu d'utiliser un tableau de tableau de char, tu pourrais sans doute envisager de "linéariser" cette matrice, le nombre de pixels que tu t'attends à extraire étant forcément égal à rowDim * colDim, l'indice de chaque pixel pouvant être calculé grâce à la formule générique index_recherche = row * colDim + col (les formules pour récupérer respectivement les lignes et les colonnes, si nécessaires, correspondant à row = index / colDim et col = index % colDim)

De manière générale, un std::vector occasionnant systématiquement 24 bytes (ce n'est peut-être que 12 en 32bits )d'utilisation mémoire de plus pour maintenir les différentes informations dont il a besoin, à savoir: un pointeur sur le début de l'espace mémoire + un espace pour contenir sa taille + un espace pour contenir sa capacité, travailler sur un tableau de tableau pour représenter une image de 27 lignes * 27 colonnes double pour ainsi dire (ou peu s'en faut) la mémoire utilisée pour la représentation de ton image, ce qui justifie amplement de faire la conversion, non

Cela ne changera rien au comportement, mais, au moins, tu éviteras les copier / coller, et s'il s'avère que tu dois modifier ce comportement, tu auras la certitude de le faire partout où il est utilisé, sans risque d'oublier de modifier le comportement de rowDim, par exemple (le fameux DRY de l'Xtrem Programming, ca te dit quelque chose )

sous windows, à partir de la moitié de l'image 5, l'affichage apparait comme si les pictureFile.get() n'étaient pas faits (toutes les valeurs sont à 0, 255 si non défini dans le resize).

Il me semble avoir été confronté (en tant qu'utilisateur) à un comportement similaire d'une application à l'époque

[BioKore]

Tout à fait d'accord concernant le extractInteger(pictureFile) c'est même entièrement au programme (j'ai bien connaissance du principe DRY )

Par contre, si j'ai bien compris (à confirmer !), en ce qui concerne la linéarisation du vecteur, ce n'est pas vraiment prévu dans le sens où ce qu'il m'importe n'est pas d'avoir un seul vecteur unique contenant toutes les images, mais bien de pouvoir récupérer un vecteur (voire un double vecteur selon les applications que j'envisage) pour chaque image récupérée. Attention, je rappelle, chaque image est ici déjà linéarisée ; si j'utilise un tableau de tableau c'est parce que j'ai 60'000 images de 28 * 28 ; j'ai donc un vecteur de 60'000 * un vecteur de 784. Je dois pouvoir en suite manipuler les images une par une et c'est bien plus pratique / ouvert de les utiliser au format std::vector que selon une structure particulière. Après, la vraie question, c'est est-ce que c'est à mon "lecteur" IDX de faire la conversion en vecteur plutôt qu'à une classe intermédiaire entre le lecteur et l'application finale ? Là, ça se discute !
Aussi, réaliser une structure permettant de tout stocker dans un seul vecteur de 47'040'000 char (plutôt que 60'000 vecteurs de 784 char) permet une économie de 1.4Mo de ram dans le cas présent soit moins de 3% de la mémoire totale utilisée par la structure.... Cela en vaut-il vraiment le coup ? Ce gain ne risque t-il pas d'être perdu dans une classe de transformation voire même d'être traduit en une perte de performance pour l'exploitation des données ?

Pour être honnête, je n'ai pas encore trop réfléchis à l'optimisation du stockage. J'ai bien conscience de l'importance de le faire dans le cas présent, mais pour le moment, ma priorité est de faire fonctionner le programme (même dans sa version la plus sommaire) sous windows. Je veillerais à faire une structure (classe ?) plus optimisée pour le stockage par la suite.

Mais merci quand même pour ces précieux conseils !

D'ailleurs, peut-on m'expliquer comment s'utilisent les outils préconisés par jo_link_noir ? Car le debuger me dit que tout va bien (avec les options données) mais j'ai tenté de donné -fsanitize=address,undefined à manger à mon compilateur et visiblement, il est pas content du tout (mingw32-g++.exe -Wall -g -pedantic -Wextra -Wall -std=c++14 -pg -Og -g -fsanitize=address -fsanitize=undefined -D_GLIBCXX_ASSERTIONS -D_LIBCPP_DEBUG=1 -D_GLIBCXX_DEBUG pour les options).
Insulte du compilateur : "internal compiler error: in pp_format, at pretty-print.c:611" Le tout dans le fichier "formatter.h", ligne 390.

Première fois que je me lance dans une opération de débogage ; soyez indulgent svp

[Bousk]

Si tes images sont de taille fixe tu peux très bien avoir 1 vector de 60000*28*28. Et accéder à une image ou l'autre est un simple index * 28 * 28