| Nom | Prenom | Pointeurs (/5) | |
| BENERRAMI | Jalel | 2 | Le champ compteur n'est pas alloue et n'est pas desalloue, le constructeur par copie ne recopie pas les champs. De plus, m et n doivent etre prives. |
| BERARD | Quentin | 4 | Le constructeur par copie doit prendre un const Matrice&, pas un Matrice&. Du coup, *(A.compteur)++ est faux pour deux raisons: ++ est prioritaire, donc cela revient a *(A.compteur++). De plus A.compteur est const, donc on ne peut pas l'incrementer. |
| BERKES | Valentin | 4 | Attention, *compteur++ revient a ecrire *(compteur++) car ++ est prioritaire sur *. C'est donc une erreur. |
| BLARRE | Auriane | 3.5 | Le destructeur s'ecrit Matrice::~Matrice, et il ne faut jamais l'appeler. En fait, tu as redefini l'operateur unaire ~ (a ne pas confondre avec le destructeur) qui fait ce qu'il faut, mais qui n'est pas appele automatiquement. Tu as une fuite memoire car il manque l'operator= pour pouvoir faire correctement C=A*B. |
| BUBBA | Federica | 1 | C'est un bon debut, mais il faut apprendre a compiler le programme et le lancer. A noter: *tab[i] devrait etre tab[i]. m n'est pas une variable membre de Matrice, il faut utiliser nlig. Tel quel, le champ compteur ne sert a rien dans ton programme. |
| COHEN | David | 4 | Attention, compteur=new int[0] cree un tableau a 0 element. Donc *compteur (equivalent de compteur[0]) n'existe pas. La methode set est a revoir, elle est dangereuse. |
| CONSTANTINI | Dan | 5 | TB. A noter que nlignes() et ncolonnes() devraient etre const. |
| CRESSOT | Loïc | 5 | TB |
| DAYAN | Sharone | 4 | Ta fonction Matrice::set provoque une fuite memoire lorsque *compteur=1 |
| DESCHAMPS | Sébastien | 4.5 | L'instruction *compteur-- dans le destructeur ne marche pas. L'operateur -- est prioritaire sur l'operateur *, donc cela decremente compteur et non *compteur. Cela se traduit par une fuite memoire dans ton programme car le compteur ne redescend jamais. |
| DING | Hongyang | 4 | Un petit pb de delete[] comp. Des erreurs dans + et * (k*nlig au lieu de k*ncol). Operator= plus complexe que necessaire. Interface un peu etrange pour random |
| DRONNIER | Dylan | 5 | TB |
| EL RHAFFOULI | Hamza | 4 | Dommage, il y avait juste une erreur *(cmp)-- au lieu de (*cmp)--. Constructeur par copie doit prendre un const Matrice& par juste Matrice&. Sinon tout le reste est juste |
| FENG | Leman | 5 | Excellent! |
| FLEURY | Madeline | 3.5 | Dans le constructeur par copie, il ne doit pas y avoir de new, simplement tab=M.tab. Dans le destructeur, inutile de faire counter=0, puisque la matrice n'existera plus. Pourquoi W+1 et H+1 dans le constructeur? W, H et counter doivent etre dans la partie privee de la classe. |
| FUJIKAKE | So | 5 | TB |
| GILLIER | Adèle | 1.5 | 'Matrice& A const' comme argument de fonction de marche pas. Tu peux faire 'const Matrice& A' ou 'Matrice const& A' a la place. Ceci corrige, il reste plusieurs erreurs: un assert incorrect dans operator*, multiplication de matrices avec tailles incompatibles. |
| HAYAT | Tom | 5 | TB. A noter que nlignes() et ncolonnes() devraient etre const. |
| KABBAJ | Hamza | 3.5 | On ne doit pas faire de new pour chaque nouvelle matrice, car il faut alors gerer le delete. Operator* ne doit pas retourner une Matrice* mais une Matrice. Le constructeur par copie devrait prendre un const Matrice& en argument. Les methodes getCompteur et setCompteur ne devraient pas exister, ou au moins etre privees. |
| LEBASTARD | Simon | 1 | Ca ne compile pas du tout, car la syntaxe n'est pas respectee: if est suivi de parentheses, certains ; manquent. New int[] n'existe pas, il faut soit new int tout court, soit new int[1]. La specialisation des template est utilisee a mauvais escient. Je prefere un programme tres partiel mais qui compile plutot que bcp de code qui ne compile pas. Pour ca, il faut commencer par faire un petit programme, compiler frequemment, et l'enrichir au fur et a mesure. |
| LEMAIGRE | Adrian | 5 | TB, mais ton operator= est potentiellement dangereux car tu fais un delete sur les anciennes donnees. C'est OK dans ton cas car la matrice ne partageait pas ses donnees. La bonne solution est de decrementer le compteur et ne faire le delete que si on atteint 0 (comme pour le destructeur) |
| LINA | Adrien | 1.5 | Pb de link qui t'empechait de voir tous les autres problemes: A+B ne fonctionne pas car les dimensions different, confusion nlig/ncol dans operator()... |
| MARGHERITI | William | 5 | TB. L'operator= n'est pas complet (ne desalloue pas les donnees precedentes), mais tu ne l'utilises pas en fait dans ton programme. |
| MARTIN | Thomas | 1.5 | Dans ton constructeur, tu as l'instruction float *tab=new float[m*n]. Cela cree une variable locale tab qui masque this->tab. D'autre part, dans le destructeur, il faut delete [] tab, compteur-- ne marche pas (faire --*compteur). |
| MILLET | Juliette | 3.5 | Pb inversion de lignes et colonnes: i*nlig+j devrait etre i*ncol+j. Dans destructeur, il faut if(*compteur==0) et non if(compteur=0): fuite memoire. |
| OUCHTAR | Eïda | 4 | Le constructeur par copie ne doit pas faire de new. Au contraire, il doit partager non seulement le tableau tab de son argument, mais aussi son compteur. Dans ton cas, le probleme se traduit par une fuite memoire. |
| PARAN | Arnaud | 4.5 | La matrice test2 du main n'est pas initialisee, TB sinon |
| SANH | Victor | 5 | TB |
| SOULIER | Eloïse | 3 | Il y a un probleme de confusion entre nlig et ncol: tab[ncol*j+i] devrait etre tab[nlig*j+i]. Dans operator+, tab[i,j] ne marche pas, l'operator [] ne prend qu'un argument. L'operator* devrait marcher meme si les matrices ne sont pas carrees. Tu ecris S=A+B, donc l'operator= est appele, et comme tu ne l'as pas defini, il provoque un probleme de memoire. |
| TROUSSARD | Martin | 4.5 | Inversion des lignes et colonnes dans le constructeur, du coup l'addition A+C ne marche pas. De plus, il faut delete compteur et non delete[]. Ceci corrige, ca fonctionne bien. |
| VESSAIRE | Cyrille | 5 | TB |
| ZEMMOURI | Youcef | 5 | TB |
| ZOUAKI | Laïla | 5 | TB |
| Nom | Prenom | STL (/5) | |
| BENERRAMI | Jalel | 5 | TB |
| BERARD | Quentin | 5 | TB |
| BERKES | Valentin | 5 | TB |
| BLARRE | Auriane | 5 | TB |
| BOULVARD | Pierre-Marie | 5 | TB |
| BUBBA | Federica | 5 | TB |
| COHEN | David | 5 | TB |
| CONSTANTINI | Dan | 5 | TB. A noter, pour appeler une methode static, on peut faire Eleve::Random() sans avoir un objet de type eleve pour appeler Random |
| CRESSOT | Loïc | 5 | TB mais attention a l'indentation |
| DAYAN | Sharone | 5 | TB |
| DESCHAMPS | Sébastien | 5 | TB |
| DING | Hongyang | 4 | Il manque le tri par nom dans le main |
| DRONNIER | Dylan | 5 | TB, attention cependant, les fcts de comparaison de la STL sont des ordres stricts (<, pas <=) |
| DUPRE | François | 5 | TB |
| EL RHAFFOULI | Hamza | 0 | Non rendu |
| FENG | Leman | 5 | Excellent ! |
| FLEURY | Madeline | 5 | TB |
| FUJIKAKE | So | 5 | TB |
| GILLIER | Adèle | 4.5 | Tu utilises le meme compteur mais tu ne le remets pas a zero entre les tris. |
| HAENTJENS | Guilain | 5 | TB |
| HAYAT | Tom | 5 | TB |
| JACOB | Etienne | 5 | TB |
| KABBAJ | Hamza | 4.5 | Tu utilises le meme compteur mais tu ne le remets pas a zero entre les tris. |
| LEBASTARD | Simon | 5 | Excellent ! Tu peux utiliser srcPath d'Imagine++ pour etre sur de trouver le fichier xml. Quelques pertes memoire associees aux new des compteurs. |
| LEMAIGRE | Adrian | 5 | TB |
| LINA | Adrien | 4 | Il faudrait afficher les listes triees, en utilisant des iterateurs. Il manque delete compteur, puisque tu as fait un new. |
| MARGHERITI | William | 4.5 | C'est bien de vouloir allouer le compteur dans le foncteur, mais du coup il y a une fuite memoire. Pour la corriger, il faut ajouter le destructeur, et pour etre robuste aux copies, definir le constructeur par copie et l'operateur= avec un compteur du nombre de copies, comme au dernier TP. Ca complique singulierement les choses. |
| MARTIN | Thomas | 5 | TB |
| MILLET | Juliette | 5 | TB |
| OUCHTAR | Eïda | 5 | TB |
| PARAN | Arnaud | 5 | TB |
| SANH | Victor | 5 | TB |
| SOULIER | Eloïse | 5 | TB |
| TROUSSARD | Martin | 5 | TB |
| VESSAIRE | Cyrille | 5 | TB |
| ZEMMOURI | Youcef | 4 | Il faudrait afficher les listes triees, en utilisant des iterateurs. |
| ZOUAKI | Laïla | 5 | TB |
| Nom | Prenom | Héritage (/5) | |
| BENERRAMI | Jalel | 3 | Fonction devrait avoir un destructeur virtuel. Les destructeurs des classes derivees n'on rien a faire. Des fuites memoire. Il ne faut pas redefinir toutes les methodes dans les classes filles, au contraire, il faut factoriser le plus possible. Affine::clone() est declare sans etre defini. |
| BERARD | Quentin | 3 | Une erreur dans Polynome::Polynome: new float(n) au lieu de new float[n], ce qui n'alloue donc qu'un seul float et provoque des erreurs memoire. Des fuites memoire. |
| BERKES | Valentin | 4 | Il y a des fuites memoire. L'interet de clone n'est pas compris. |
| BLARRE | Auriane | 1 | De multiples erreurs de compilation, et tres incomplet. |
| BOULVARD | Pierre-Marie | 0 | non rendu |
| BUBBA | Federica | 3.5 | Il faut factoriser le plus possible. Definir Fonction::inverse generique n'empeche pas de specialiser pour Trigo ou Affine, puisque la fonction est virtuelle. Des fuites memoire suite a l'appel de derivee, qui alloue de la memoire. |
| COHEN | David | 4 | inverse devrait etre defini au niveau de Fonction pour plus de generalite. Des fuites memoire dans cette methode car l'appel a derivee alloue de la memoire. |
| CONSTANTINI | Dan | 4.5 | Fuite memoire dans inverse (il faut faire un delete D). L'interet de clone n'est pas reellement compris. |
| CRESSOT | Loïc | 4.5 | Fuite memoire dans inverse |
| DAYAN | Sharone | 4 | inverse devrait etre defini au niveau de Fonction pour plus de generalite. Des fuites memoire dans cette methode car l'appel a derivee alloue de la memoire. L'interet de clone n'est pas compris. |
| DESCHAMPS | Sébastien | 4 | Le destructeur de Fonction devrait faire delete integrale, sinon il y a des fuites memoire. Fuite memoire dans inverse, car derivee alloue de la memoire. |
| DING | Hongyang | 4 | inverse doit se mettre au niveau de Fonction. Fuite memoire issue de derivee() |
| DRONNIER | Dylan | 4.5 | Il manque la liberation memoire issue de derivee dans inverse. Fonction::derivee devrait appeler clone(), qui devrait donc etre virtuel au niveau de Fonction. |
| DUPRE | François | 1.5 | La methode inverse n'est pas implementee. |
| EL RHAFFOULI | Hamza | 0 | non rendu |
| FENG | Leman | 5 | Parfait! |
| FLEURY | Madeline | 3.5 | Il ne faut pas appeler clone sur une Fonction, seulement sur une classe fille, car le champ integrale est alors partage. Ou alors, il faut cloner aussi le champ integrale s'il est non nul. Il y a donc des erreurs memoire dans ton programme dans Trigo::derivee() |
| FUJIKAKE | So | 5 | TB. Il n'est pas vraiment utile de stocker a et b dans Affine, il vaut mieux se servir du vecteur de Polynome. |
| GILLIER | Adèle | 2 | La methode clone n'est pas implementee dans les sous-classes, ce qui explique l'echec de cube.inverse(27). De plus, la methode inverse devrait etre dans Fonction elle-meme, pas dans Polynome, pour etre la plus generique possible. |
| HAENTJENS | Guilain | 0 | non rendu |
| HAYAT | Tom | 4.5 | Fuite memoire issue de derivee() dans inverse. L'interet de clone n'est pas compris. |
| JACOB | Etienne | 0 | non rendu |
| KABBAJ | Hamza | 4 | Il faut factoriser dans Fonction tout ce qu'on peut, en particulier inverse. C'est autant de moins a ecrire pour les classes filles. Fuites memoire suite a l'appel de derivee. |
| LEBASTARD | Simon | 3 | Il manque un destructeur virtuel dans Fonction. Il y a un probleme, car d'apres le programme 'La racine cubique de 27 est 6'... La methode inverse generique ne doit etre implementee qu'une fois, au niveau de Fonction. |
| LEMAIGRE | Adrian | 4 | inverse devrait etre dans Fonction et non dans Polynome, et faire attention de liberer la memoire issue de derivee(). A noter que return P; delete P; ignore le delete car return sort immediatement. Heureusement, sinon tu aurais un crash dans ton programme. |
| LINA | Adrien | 4 | Des fuites memoire suite a l'appel de Fonction::derivee() |
| MARGHERITI | William | 4 | La methode inverse devrait etre factorisee au niveau de Fonction et non dupliquee dans Polynome et Trigo. Fuite memoire suite a un clone(): il faut un destructeur a Fonction fait un delete integrale. |
| MARTIN | Thomas | 4 | inverse devrait etre au niveau de Fonction et prendre garde a liberer la memoire allouee par derive. La methode clone n'a un interet que si on fait jouer les methodes virtuelles, sinon autant faire un new directement. |
| MILLET | Juliette | 3.5 | Il ne faut pas appeler clone sur une Fonction, seulement sur une classe fille, car le champ integrale est alors partage. Ou alors, il faut cloner aussi le champ integrale s'il est non nul. Il y a donc des erreurs memoire dans ton programme dans Trigo::derivee(). De plus, le destructeur des classes derivees ne doivent pas detruire integrale, c'est la classe Fonction qui le fera lorsque son destructeur sera appele. |
| OUCHTAR | Eïda | 3.5 | Le bug vient de Trigo::derivee, qui fait que D et l'objet retourne partagent le meme champ integrale, qui sera donc detruit deux fois. Fuite memoire dans inverse, qui devrait d'ailleurs etre dans Fonction. |
| PARAN | Arnaud | 5 | TB, meme plus que ce qui etait demande ! |
| SANH | Victor | 4 | Polynome::inverse devrait etre Fonction::inverse. Il y a une fuite memoire dans cette methode. |
| SOULIER | Eloïse | 0 | non rendu |
| TROUSSARD | Martin | 3.5 | Il faut factoriser au maximum dans les classes mere, en particulier inverse. Fuites memoire suite a l'appel de derivee, qui alloue de la memoire. |
| VESSAIRE | Cyrille | 2.5 | inverse devrait etre factorise au niveau de Fonction. Quel est le role de la methode Integrale? Il ne faut pas redefinir chaque methode dans les classes filles, au contraire il faut s'appuyer sur les classes meres autant que possible. |
| ZEMMOURI | Youcef | 2 | Polynome et Trigo ont des methodes virtuelles pures, donc on ne peut pas creer d'objets de ce type. En fait, s'il y a des methodes virtuelles pures a mettre, elles seraient au niveau de la classe de base, Fonction. |
| ZOUAKI | Laïla | 4 | Il y a des fuites memoire au niveau de inverse, car derivee alloue de la memoire a chaque appel, qu'il faut penser a liberer. Dans Affine, ne pas stocker a et b en plus des coeffs du polynome, c'est redondant. |
| Nom | Prenom | CmdLine (/5) | |
| BENERRAMI | Jalel | 4.5 | TB. Il y a juste un petit probleme dans la traduction d'un char en string, qui fait une erreur memoire car un char* passe a un string suppose que c'est un tableau dont le dernier element est indique par la valeur 0. |
| BERARD | Quentin | 2.5 | Le code fonctionne, mais le principe du CmdLine n'est pas applique. Le programme doit obtenir ses arguments par main(int argc, char* argv[]), et non en demandant une ligne a l'utilisateur. |
| BERKES | Valentin | 3 | Ca ne compile pas : que vient faire ce #include <windows.h>. Meme apres retrait, il y a un probleme avec stringstream::operator=. Il y a quelques variables non initialisees dans la structure tm. |
| BLARRE | Auriane | 0 | non rendu |
| BOULVARD | Pierre-Marie | 1 | La syntaxe du C++ n'est absolument pas respectee et la liste des changements a apporter pour que le programme compile est longue. |
| BUBBA | Federica | 1.5 | Pas mal de problemes de compilation. Par exemple, Option doit se trouver avant CmdLine car CmdLine utilise Option. Il faut reouvrir le namespace pour la definition des methodes dans le cpp. |
| COHEN | David | 4.5 | Fuite memoire: si make_option retourne un Option*, le clone dans add devient superflu. La specialisation make_option<bool> est inutile, le code generique suffit. L'option -a ne marche pas (mais l'option longue annee si) |
| CONSTANTINI | Dan | 4 | La variable annee du main n'est jamais initialisee si l'option correspondante n'est pas appelee. Fuites memoire car make_option fait un new et add fait un clone (donc aussi un new). Il est inutile de specialiser toute la classe OptionField<bool>, seules quelques methodes suffisent. |
| CRESSOT | Loïc | 4 | Le fonctionnement du programme est correct, mais il manque la gestion des fonctions de temps. D'autre part, l'argument d'une option longue comme year devrait suivre par un =2016 accroche, pas 2016 separe. |
| DAYAN | Sharone | 3.5 | Le programme ne detecte pas correctement l'option -a ou annee. La variable year du main est donc non initialisee. Fuite memoire du fait que make_option fait un new et add appelle clone, donc un deuxieme new. Un seul est detruit par ~CmdLine. |
| DESCHAMPS | Sébastien | 1.5 | Le probleme de link vient de Option::decode qui est declare mais non defini. Il faut mettre cette methode virtuelle pure (=0) pour corriger le probleme. Apres cela, le programme a plusieurs bugs en lui-meme et ne fonctionne pas correctement. |
| DING | Hongyang | 4 | L'ensemble fonctionne plutot bien. Cependant clone est inutilise (ce serait mieux que de faire renvoyer un Option* a make_option) et les options decodees ne sont pas supprimees. |
| DRONNIER | Dylan | 4 | Bien dans l'ensemble. La fonction clone n'est pas utilisee car ton make_option renvoie une Option* allouee, ce qui est effectivement une solution. Quelques problemes memoire avec les options longues. |
| DUPRE | François | 3.5 | Les options longues avec un double - ne marchent pas (crash). De plus, la comparaison a l'option courte a aussi une erreur memoire: un char* doit se terminer par zero, donc attention quand on en cree un a la main. Il est plus sur d'utiliser les std::string. De plus, la methode de verification des options devraient retirer celles-ci de la liste des arguments lors de leur decodage. La presence de ces options est verifiable par la variable associee. |
| EL RHAFFOULI | Hamza | 0 | non rendu |
| FENG | Leman | 4 | OK, mais il faut analyser les argc/argv du main. Les consignes ne sont pas tout a fait respectees: l'argument de l'option longue annee doit etre colle avec un =. Une erreur memoire pour les options sans arugments, acces a it+1 qui peut etre end. |
| FLEURY | Madeline | 4 | Plutot bien dans l'ensemble, mais quelques problemes memoire de depassement de limite dans les chaines de caracteres, fuite memoire (manque destructeur de CmdLine), un try/catch autour de process aurait aussi ete bienvenu. |
| FUJIKAKE | So | 4.5 | TB. Plutot que d'utiliser un champ exec pour savoir si une option a ete utilisee ou non, il faut verifier par les variables associees aux options. De plus, process est suppose filtrer les arguments: les options decodees devraient etre enlevees apres appel. |
| GILLIER | Adèle | 0 | non rendu |
| HAENTJENS | Guilain | 0 | non rendu |
| HAYAT | Tom | 4.5 | Le programme marche correctement dans l'ensemble, mais il y a quand meme une fuite memoire car make_option fait un new et add fait un clone, ce qui fait deux new et un seul delete (dans ~CmdLine) |
| JACOB | Etienne | 0 | non rendu |
| KABBAJ | Hamza | 2.5 | Un probleme de link car le constructeur de OptionField<bool> est defini dans un .h inclus plusieurs fois. Il faut le transferer dans Option.cpp. Apres correction, le programme ne fait rien pour les options connues et tourne a l'infini pour une option inconnue. |
| LEBASTARD | Simon | 1.5 | De nombreux problemes empechant la compilation, entre autres une conversion de int* en int, construction d'exceptions avec un argument (pas de constructeur prenant un char* dans std::exception), etc |
| LEMAIGRE | Adrian | 4 | OK, mais la machinerie de CmdLine devrait etre independante du programme specifique et communiquer avec l'exterieur uniquement par les variables. |
| LINA | Adrien | 2 | Le constructeur de OptionField doit prendre un T& et non un T comme dernier argument start, car value=&start doit faire pointer value sur une variable perenne. Avec un T tout court, on pointe sur une variable qui n'existe plus une fois sorti du constructeur, d'ou crash quand on essaie d'ecrire dedans. Ceci dit, meme avec cette correction, le programme ne fait rien. |
| MARGHERITI | William | 1 | Il y a de serieux problemes de syntaxe avec les templates. |
| MARTIN | Thomas | 2 | Le probleme de link que tu avais vient du fait que tu avais deux fonctions clone dans Option, une const et une non, seule la premiere etant definie. Il suffit de retirer la deuxieme pour que ca se passe bien. Ceci corrige, comme tu n'as pas pu tester, il reste pas mal de bugs. En particulier, argv[0] ne doit pas etre considere comme un argument, c'est le nom du programme. D'autre part, faire try { throw } catch est un peu inutile, le try/catch devrait entourer une fonction qui peut faire un throw, le but de throw est d'envoyer un message a la fonction appelante, pas a soi-meme. |
| MILLET | Juliette | 2 | Ca ne compile pas a cause de plusieurs problemes. De plus, la machinerie de CmdLine n'est pas generique, elle est specifique au programme particulier traite, la seule communication avec le main doit etre par l'intermediaire des variables. |
| OUCHTAR | Eïda | 1.5 | Il y a plusieurs problemes a corriger avant de pouvoir compiler: il manque des constructeurs sans arguments, les mots-cles true et false ne prennent pas de majuscule, etc. |
| PARAN | Arnaud | 0 | non rendu |
| SANH | Victor | 3.5 | Il manque un destructeur dans CmdLine: comme add fait un new (par l'intermediaire de clone), il faut liberer la memoire dans le destructeur. Les variables associees aux options ne sont pas utilisees, et la machinerie du CmdLine n'est pas generique car elle est specialisee pour ce programme de test. |
| SOULIER | Eloïse | 0 | non rendu |
| TROUSSARD | Martin | 0 | non rendu |
| VESSAIRE | Cyrille | 0 | non rendu |
| ZEMMOURI | Youcef | 1.5 | Le principal probleme de compilation provient du fait que la fonction virtuelle pure check d'Option n'a pas les memes arguments que celle d'OptionField, ce qui fait qu'OptionField reste une classe abstraite. D'autre part, le contenu du .cpp pour des templates doit etre dans le .h, sinon ca pose des problemes au linker |
| ZOUAKI | Laïla | 4.5 | TB point de vue gestion memoire et fonctionnalite. Cependant, il faudrait separer la gestion des options de ce programme specifique newyear de CmdLine, la communication entre les deux devrait se faire uniquement par l'intermediaire des variables. |
| Nom | Prenom | DistEdit (/5) | |
| BENERRAMI | Jalel | 2.5 | Preuve incomplète, version récursive inintéressante (où est la programmation dynamique ?), ne pas mettre de code dans le rapport, factoriser le code |
| BERARD | Quentin | 4.5 | Transfos OK mais mais pas très lisibles à l'affichage. Rapport OK. Il manque la question de la version linéaire en espace. |
| BERKES | Valentin | 4.5 | Il manque la preuve de sous-structure optimale, OK pour le reste du rapport. Le code manque de commentaires. Transfos OK mais mais pas très lisibles à l'affichage. |
| BLARRE | Auriane | 2.5 | Il manque la preuve de sous-structure optimale. Programmation récursive exponentielle : pas programmation dynamique (polynomiale) ici. |
| BOULVARD | Pierre-Marie | 3 | Preuve OK mais notations manquantes. Manquent : interface minimale, DL, modifs élémentaires, version linéaire en espace, commentaires dans le code |
| BUBBA | Federica | 2.5 | Preuve pas très claire. Le code de démo ne compile pas (trop nettoyé?). Manquent : interface minimale, DL, modifs élémentaires, version linéaire en espace. |
| COHEN | David | 4.5 | Code un peu laborieux, manque la version linéaire en espace |
| CONSTANTINI | Dan | 5 | TB |
| CRESSOT | Loïc | 5 | Rapport OK. Programmation dynamique via récursivité et mémoïzation OK bien que solution de facilité. |
| DAYAN | Sharone | 5 | TB |
| DESCHAMPS | Sébastien | 5 | Créer des lignes et colonnes factices n'est pas une bonne économie par rapport à des tests d'indices. Dans la version linéaire on peut éviter les copies avec un jeu d'indices. |
| DING | Hongyang | 4 | Preuve de sous-structure optimale manquante. Pour la version linéaire, on a besoin d'une taille 2*min(m,n), pas m+n. Faire la version memoisée est facile, regarder plutôt la version itérative |
| DRONNIER | Dylan | 4 | Preuve incomplète, code OK, bug dans l'affichage des explications (essayer ./distance.out aze zer) |
| DUPRE | François | Non rendu | |
| EL RHAFFOULI | Hamza | Non rendu | |
| FENG | Leman | 5 | Preuve un peu laborieuse. Pour la version linéaire, deux colonnes ou deux lignes suffisent, c'est plus simple. |
| FLEURY | Madeline | 3.5 | Il manque la preuve de sous-structure optimale. Erreur dans l'affichage des tranfos. Bug dans la distance DL (essayer d(ab,ba)). Eviter d'inclure inutilement du code via des .h. |
| FUJIKAKE | So | 4.5 | Preuve pas très claire (en partie due aux difficultés de langue), codage un peu fastidieux (pourrait être plus court). On peut faire une version linéaire sans recopie. |
| GILLIER | Adèle | 4.5 | Bien. Manque version linéaire en espace. « Translation » => « Transposition » |
| HAENTJENS | Guilain | 3.5 | Ne raconter pas sa vie dans le rapport, livrer un code propre(juste le source+CMake), éviter d'inclure inutilement du code via des .h, interface inexistante, bug dans DL et versions « suivies » |
| HAYAT | Tom | 5 | TB. |
| JACOB | Etienne | 3.5 | Explication des transformations fausse. Manquent : sous-structure optimale, DL, version linéaire en espace |
| KABBAJ | Hamza | 3 | Le rapport est daté du 12 mai, je n'attendais pas un nouveau travail. Rapport minimal. La preuve n'a pas beaucoup de sens, la complexité n'est pas indiquée. Manque la distance DL et la version linéaire en espace. |
| LEBASTARD | Simon | 4.5 | Bon code, bon rapport, dommage qu'il manque la question de la version linéaire en espace. |
| LEMAIGRE | Adrian | 5 | TB |
| LINA | Adrien | 2.5 | Rapport OK, dommage qu'il manque la preuve. Dans la version linéaire on peut éviter les copies avec un jeu d'indices. Code erroné (ne calcule pas les bonnes distances) |
| MARGHERITI | William | 5 | Excellent travail. Très bon rapport, un peu laborieux mais méticuleux. Code bien indenté et bien commenté, ça fait plaisir. |
| MARTIN | Thomas | 2 | Le code ne compile pas (nombreuses erreurs). Manquent : DL, explication des modifs élémentaires, version linéaire en espace, commentaires dans le code |
| MILLET | Juliette | 2 | Pas de programmation dynamique ici, il n'y a que la version récursive, de complexité exponentielle. Transformations affichées peu lisibles. |
| OUCHTAR | Eïda | 4 | Preuve de sous-structure optimale un peu courte, revoir l'allocation dynamique (avec new), dommage que les transfos ne marchent pas pour DL. Manque la version linéaire en espace |
| PARAN | Arnaud | Non rendu | |
| SANH | Victor | 4 | Dommage pour la preuve. OK pour les transfos élémentaires mais on ne sait pas à quel endroit dans le mot elles s'appliquent. |
| SOULIER | Eloïse | 3 | Manquent : preuve, DL, modifs élémentaires, version linéaire en espace, commentaires dans le code |
| TROUSSARD | Martin | 4 | Ne raconter pas sa vie dans le rapport. Manquent : DL, version linéaire en espace |
| VESSAIRE | Cyrille | 3 | Eviter les duplications de code, interface inexistante, libérer l'espace, valeur retournée erronée (erreur d'indice) => code non testé ???, manque version linéaire en espace |
| ZEMMOURI | Youcef | 3.5 | Manquent : modifs élémentaires (qui marchent), version linéaire en espace, commentaires dans le code |
| ZOUAKI | Laïla | 4 | Utiliser « Matrice » est un overkill. Dommage qu'il manque un mini-rapport (avec la preuve). Manque aussi la version linéaire en espace |
| Nom | Prenom | DataStruct (/5) | |
| BENERRAMI | Jalel | 4.5 | Ne pas détruire un nœud avant d'avoir détruit ses fils (risque d'écrasement), try-catch dans une même fonction est inutile pour la gestion d'erreur (cf. transparent p.50), maxDepth inutilement compliqué (alloc mémoire inutile), minDepth inefficace (parcourt tout l'arbre) |
| BERARD | Quentin | 2 | Cas pos<0 oublié, cas newSon=NULL aussi. Code truffé d'erreurs qui n'a jamais été compilé. Fonction display inutilement compliquée. Destructeur qui n'a pas de sens. |
| BERKES | Valentin | 5.5 | Réponses aux questions un peu brèves. On peut signaler aussi newSon=NULL dans setSon et addAsLastSon. Il faut implémenter une fonction maxDepth qui n'alloue pas de mémoire. Usage de « tuple » au lieu de « pair » un peu lourd. |
| BLARRE | Auriane | 3 | intTree.h et rapport manquants. Cas pos<0 oublié, cas newSon=NULL aussi. Pour lever une exception, préférer un sous-type de exception (STL) plutôt qu'une chaine de caractères. Destructeur erroné (la récursivité est donnée automatiquement par delete) |
| BOULVARD | Pierre-Marie | 1.5 | Pas de réponse aux questions. sons.clear() inutile dans le constructeur. Manquent : gestion d'erreur, destructeur, display avec indentation. |
| BUBBA | Federica | 4 | Pour Ex2.1 les cas d'erreur de getData et setData n'ont pas de sens (car fait pas le compilateur). Pour Ex2.2, ça n'a pas de sens de retourner FLTMAX pour un entier. Les « this-> » sont inutiles. Cas pos<0 oublié pour getSon. |
| COHEN | David | 6 | TB. Dommage qu'il manque l'implémentation de l'exercice 5. |
| CONSTANTINI | Dan | 5 | TB. On peut signaler aussi newSon=NULL dans setSon et addAsLastSon. |
| CRESSOT | Loïc | 6.5 | TB. On peut aussi calculer minDepth sans allouer de mémoire et sans parcourir tout l'arbre en élaguant un parcours en profondeur. L'impossibilité d'afficher avec « cout << » se traduit par une erreur de type à la compilation, pas une exception. |
| DAYAN | Sharone | 5 | TB |
| DESCHAMPS | Sébastien | 4.5 | On peut signaler aussi newSon=NULL dans setSon et addAsLastSon. « delete this » n'a pas de sens dans le destructeur. Pour lever une exception, préférer un sous-type de exception (STL) plutôt qu'une chaine de caractères. Il manque indent dans l'appel récursif de display. |
| DING | Hongyang | 5.5 | On peut signaler aussi newSon=NULL dans setSon et addAsLastSon. Erreur dans display (il faut ajouter indent, pas " "). Contrôler pos<0 dans addSon et removeSon |
| DRONNIER | Dylan | 5.5 | minDepth inefficace car parcourt tout l'arbre, info d'erreur pas très explicite (out_of_range("out of range")), gestion d'erreur OK (mais dommage qu'il manque la discussion demandée) |
| DUPRE | François | 1.5 | try-catch dans une même fonction est inutile pour la gestion d'erreur (cf. transparent p.50), certaines fonctions n'ont jamais été testées (ex. bug setData), des initialisations inutiles (ex. sons), display ne marche pas |
| EL RHAFFOULI | Hamza | Non rendu | |
| FENG | Leman | 6.5 | TB. On peut aussi calculer minDepth sans allouer de mémoire et sans parcourir tout l'arbre en élaguant un DFS. |
| FLEURY | Madeline | 4 | try-catch dans une même fonction est inutile pour la gestion d'erreur (cf. transparent p.50). display est incorrect : pour qu'indent ne croit exponentiellement avec la profondeur, il faut l'ajouter à prefix, pas à indent. Pour lever une exception, préférer un sous-type de exception (STL) plutôt qu'une chaine de caractères. |
| FUJIKAKE | So | 6 | On peut signaler aussi newSon=NULL dans setSon et addAsLastSon. Les « this-> » sont inutiles. On peut aussi trouver minDepth sans allouer de mémoire. On peut faire plus simple pour display en construisant une string dans laquelle on fait « +indent » à chaque fois qu'on descend d'un niveau. |
| GILLIER | Adèle | 4 | Réponse à Ex2.3 inutilement compliquée (rang inutile). Pour lever une exception, préférer un type exception plutôt qu'un entier. Cas pos<0 oublié. |
| HAENTJENS | Guilain | Non rendu | |
| HAYAT | Tom | 4.5 | On peut signaler aussi newSon=NULL dans setSon et addAsLastSon. Ex3.2 : -1 n'est pas a priori une valeur incohérente. On parle des « feuilles » de l'arbre, pas de ses « pieds ». |
| JACOB | Etienne | Non rendu | |
| KABBAJ | Hamza | 4.5 | Rapport très détaillé. Erreur dans display (indent croit exponentiellement avec la profondeur). Il est suffisant et recommandé quand c'est possible d'utiliser les exceptions prédéfinies dans la STL. On peut signaler aussi newSon=NULL dans setSon et addAsLastSon. Les « this-> » sont inutiles. sons.pop_back() est inutile dans le destructeur. |
| LEBASTARD | Simon | 6 | TB. Destructeur inutilement compliqué. On peut signaler aussi newSon=NULL dans setSon et addAsLastSon. |
| LEMAIGRE | Adrian | 6.5 | TB. Code plus riche que ne le laisse penser le rapport, qui peut sembler incomplet (ex. cas pos<0 oublié). |
| LINA | Adrien | 1 | Code truffé d'erreurs de compilation (« ; » oublié, Tree<T> :: oublié, fonction main absente, etc.). Plagiat de Cyril Vessaire ? => note divisée par 2. |
| MARGHERITI | William | 4.5 | Des réponses à Ex3.1 erronées : c'est le compilateur qui signale les erreurs de type. 3.2 : vous mélangez valeur de retour et affichage par cerr. Dommage qu'il manque la gestion d'erreur |
| MARTIN | Thomas | 3.5 | « statut d'erreur » est défini dans le cours. On peut signaler aussi newSon=NULL dans setSon et addAsLastSon. Inutile de créer de nouvelles classes d'exception, utiliser celles de la STL. Affecter data à 0 dans le destructeur n'a pas de sens. Il manque l'indentation de display. |
| MILLET | Juliette | 3.5 | Pas de mini-rapport avec les réponses aux questions. « if (data == NULL) » n'a pas de sens (comparaison d'un entier avec un pointeur). Pour lever une exception, préférer un sous-type de exception (STL) plutôt qu'une chaine de caractères. removeLastSon ne fait pas ce qu'on lui demande. |
| OUCHTAR | Eïda | 5.5 | Rapport un peu succinct. On peut signaler aussi newSon=NULL dans setSon et addAsLastSon. |
| PARAN | Arnaud | Non rendu | |
| SANH | Victor | 5.5 | Mini-rapport (réponses aux questions) manquant. minDepth appelle maxDepth !, la fonction n'a pas dû beaucoup être testée (et dans tous les cas elle fait inutilement un parcours complet de l'arbre). sons.pop_back() inutile dans le destructeur. On peut signaler aussi newSon=NULL dans setSon et addAsLastSon. |
| SOULIER | Eloïse | 4 | Cas pos < 0 oublié pour getSon et setSon, cas newSon=NULL aussi. Pour lever une exception, préférer un sous-type de exception (STL) plutôt qu'un entier ou une chaine de caractères. |
| TROUSSARD | Martin | 2.5 | Service minimum, c'est dommage. |
| VESSAIRE | Cyrille | 1 | On parle de parcours « en profondeur » et non « en hauteur ». « delete[] sons » est inutile. Cas pos<0 oublié. Idem pour newSon=NULL. Pour addSon et removeSon, utiliser vector::insert et vector::erase. Pour lever une exception, préférer un sous-type de exception (STL) plutôt qu'une chaine de caractères. Le code fournit « ne compile pas », pensez à fournir un CMakeLists.txt. Plagiat de Adrien Lina ? => note divisée par 2. |
| ZEMMOURI | Youcef | 4.5 | On peut signaler aussi newSon=NULL dans setSon et addAsLastSon. Justifier le choix de la gestion d'erreur. |
| ZOUAKI | Laïla | 6 | TB. On peut signaler aussi newSon=NULL dans setSon et addAsLastSon. Pour le BFS, utiliser le type queue, plus efficace ici que vector (qui fait des copies à chaque erase(begin())). On peut faire un minDepth qui n'alloue pas de mémoire (élaguer le parcours au fur et à mesure qu'on a une borne sup sur minDepth) |
| Nom | Prenom | Quadtree (/5) | |
| BENERRAMI | Jalel | Non rendu | |
| BERARD | Quentin | Non rendu | |
| BERKES | Valentin | 5 | Très bon travail. On peut éviter de libérer/réallouer de la mémoire quand on veut insérer sur une feuille. |
| BLARRE | Auriane | 4 | Fournir du code nettoyé. Mettre le code exécutable dans des .cpp, pas dans des .h (sauf si impossible de faire autrement, p.ex. template). La mesure de compression est fausse (il manque les feuilles et la taille d'un noeud n'est pas comparable à un byte) et le terme profondeur est inadapté. Pour une décompression efficace, remplir un tableau et ne l'afficher qu'à la toute fin. |
| BOULVARD | Pierre-Marie | 0.5 | Code très partiel et non testé, pas de mini-rapport. |
| BUBBA | Federica | 1.5 | Code très partiel, pas de mini-rapport. |
| COHEN | David | Non rendu | |
| CONSTANTINI | Dan | 4 | Il ne faut pas tester explicitement si une zone est uniforme (re-parcours inutiles à chaque niveau), on le découvre à la remontée des appels récursifs si on récupère 4 feuilles de même intensité/couleur. Si la dimension de l'image n'est pas une puissance de deux, ne créer explicitement une sur-image carrée, le faire virtuellement. La mesure de compression est fausse : la place que prend un quadtree n'est pas égale à 1 bit par feuille. |
| CRESSOT | Loïc | 2 | Bonne analyse et bon recul malgré les difficultés rencontrées. Votre définition de == et != pour Point2D et Town passe sur mon compilateur, mais j'obtiens un Segmentation fault à l'exécution après l'insertion d'un soixantaine de villes. Dommage, le code contient de bonnes choses. |
| DAYAN | Sharone | 3 | Il ne faut pas tester explicitement si une zone est uniforme (re-parcours inutiles à chaque niveau). La mesure de compression est fausse (il manque les feuilles et la taille d'un noeud n'est pas comparable à un byte). Le niveau de gris (compression avec perte) n'est pas traité. |
| DESCHAMPS | Sébastien | 5 | Bon rapport. Il ne faut pas tester explicitement si une zone est uniforme (re-parcours inutiles à chaque niveau), on le découvre à la remontée des appels récursifs si on récupère 4 feuilles de même intensité/couleur. Attention taux de compression surévalué car la taille d'une intensité de pixel est nettement plus petite que la taille d'un nœud (disponible via « sizeof »). |
| DING | Hongyang | 4.5 | Pour trouver le plus proche voisin, utiliser un seuil de 0.005 n'est pas sûr et est spécifique aux données. Il faut appliquer la méthode du cours (p.65). Bon travail pour le reste. |
| DRONNIER | Dylan | 5 | Très bon travail. On peut éviter de libérer/réallouer de la mémoire quand on veut insérer sur une feuille. L'affichage prend toujours du temps : le supprimer pour faire des mesures plus précises dans la boucle de rapidite.cpp, ça donne des résultats encore meilleurs. |
| DUPRE | François | 5 | Ne fournir que des fichiers utiles, nettoyés, ainsi qu'un CMakeLists.txt. Pour le square s initial, prendre une taille+marge avec marge>0.1 sinon il peut y avoir des villes hors bounding box (ça bogue sur mon ordi) mais en fait c'est inutile de prendre des marges puisqu'on retourne xmin et ymin. Des commentaires seraient les bienvenus. |
| EL RHAFFOULI | Hamza | Non rendu | |
| FENG | Leman | 5 | TB |
| FLEURY | Madeline | 5 | Très bon rapport. Il est inutile de tester si une zone est uniforme (re-parcours inutiles à chaque niveau), on le découvre à la remontée de vos appels récursifs si on récupère 4 feuilles de même intensité/couleur. Attention taux de compression surévalué car la taille d'une intensité de pixel est nettement plus petite que la taille d'un nœud (disponible via « sizeof »). |
| FUJIKAKE | So | 5.5 | Excellent rapport. Excellent travail. Pour search, dans le cas où on atteint une feuille, on peut éviter de libérer de la mémoire pour la réallouer peu après. Fournir une archive nettoyée (sources sans binaire). |
| GILLIER | Adèle | 4 | Il ne faut pas tester explicitement si une zone est uniforme (re-parcours inutiles à chaque niveau), on le découvre à la remontée des appels récursifs si on récupère 4 feuilles de même intensité/couleur. Il est inutile de construire explicitement une image carré qui contient l'image rectangulaire. Oui, utiliser la moyenne sur la région quasi-uniforme (à la fois pour le test de similarité et pour l'affectation d'une nouvelle couleur) donne de meilleurs résultats visuels. Construire l'arbre bottom-up au lieu de créer une racine et de le construire par en haut. |
| HAENTJENS | Guilain | Non rendu | |
| HAYAT | Tom | 3 | On demandait de ne pas modifier quadtree.h. Il ne faut pas tester explicitement si une zone est uniforme (re-parcours inutiles à chaque niveau), on le découvre à la remontée des appels récursifs si on récupère 4 feuilles de même intensité/couleur. Une structure comme ImageCut n'est pas nécessaire et crée des allocations inutiles. Il y a des opérations exponentielles (appel de nbNodes dans EncodageNiveaugrisLissage). Ça alloue beaucoup, ça ne libère jamais. Bug dans l'encodage en niveau de gris (prendre threshold = 100, on ne voit pas de gros carrés). |
| JACOB | Etienne | Non rendu | |
| KABBAJ | Hamza | 4.5 | L'introduction des classes Image et Frame est bien compliquée, on peut faire plus simple. Il ne faut pas tester explicitement si une zone est uniforme (re-parcours inutiles à chaque niveau), on le découvre à la remontée des appels récursifs si on récupère 4 feuilles de même intensité/couleur. |
| LEBASTARD | Simon | 5 | Il ne faut pas tester explicitement si une zone est uniforme (re-parcours inutiles à chaque niveau), on le découvre à la remontée des appels récursifs si on récupère 4 feuilles de même intensité/couleur. On peut trouver des noms de variables plus explicites que « ab » et « or ». TB pour l'exercice sur les arbres binaires. |
| LEMAIGRE | Adrian | 4.5 | Il ne faut pas tester explicitement si une zone est uniforme (re-parcours inutiles à chaque niveau), on le découvre à la remontée des appels récursifs si on récupère 4 feuilles de même intensité/couleur. Ce que vous appelez « taux de compression » est plutôt 1-taux. |
| LINA | Adrien | 2.5 | Dommage, vous n'étiez pas loin : pour faire marcher votre code, il suffit de passer qt par référence dans encode (avec « & »). |
| MARGHERITI | William | 4 | Il faut parcourir l'image et construire le quadtree optimisé au vol (sans construire de quadtree non optimisé d'abord). Il y a plein de construction de nœuds de quadtree inutiles. Le taux de compression est surestimé car un nœud prend plus de place qu'un pixel. Pour le décodage, ne pas allouer plein de petites imagettes (new byte[w*w]) : allouer une seule grande image et écrire dedans en parcourant le quadtree. |
| MARTIN | Thomas | 1.5 | Ne pas raconter sa vie dans le rapport. Dans le cas d'un damier, le taux de compression n'est pas 1 (il ne pourrait être proche de 1 que si l'image était toute blanche ou toute noire). Ça n'a pas de sens d'appeler la variable image « Horse ». Il ne faut pas tester explicitement si une zone est uniforme (re-parcours inutiles à chaque niveau), on le découvre à la remontée des appels récursifs si on récupère 4 feuilles de même intensité/couleur. Il y a de l'idée mais la récursion pour créer le quadtree n'est pas comprise (la fonction doit retourner un quadtree correspondant à la zone encodée). |
| MILLET | Juliette | 3.5 | Il ne faut pas tester explicitement si une zone est uniforme (re-parcours inutiles à chaque niveau), on le découvre à la remontée des appels récursifs si on récupère 4 feuilles de même intensité/couleur. Attention votre taux de compression est surévalué car la taille d'une intensité de pixel est nettement plus petite que la taille d'un nœud (disponible via « sizeof »). Il y a un bug dans votre compression avec niveau de gris (voir par ex. à gauche du chapeau de Lena). |
| OUCHTAR | Eïda | Non rendu | |
| PARAN | Arnaud | Non rendu | |
| SANH | Victor | 4 | Ne pas raconter sa vie dans le rapport. Il doit y avoir un léger bug car Avranches n'est pas la ville la plus proche de Ponts (mais presque). Le nombre de noeuds parcouru est aussi anormalement élevé (il devrait être de l'ordre de quelques centaines). |
| SOULIER | Eloïse | 1 | Il ne faut pas tester explicitement si une zone est uniforme (re-parcours inutiles à chaque niveau), on le découvre à la remontée des appels récursifs si on récupère 4 feuilles de même intensité/couleur. Pour la récursion de décodage, il faut juste tester les deux cas feuille ou nœud, et dans le cas nœud, appeler récursivement chacun des 4 fils. |
| TROUSSARD | Martin | Non rendu | |
| VESSAIRE | Cyrille | Non rendu | |
| ZEMMOURI | Youcef | Non rendu | |
| ZOUAKI | Laïla | 3 | Il ne faut pas tester explicitement si une zone est uniforme (re-parcours inutiles à chaque niveau), on le découvre à la remontée des appels récursifs si on récupère 4 feuilles de même intensité/couleur. Le taux de compression est surestimé car un nœud prend plus de place qu'un pixel. |
| Nom | Prenom | Isotopo (/5) | |
| BENERRAMI | Jalel | 3.5 | N et C sont sous-estimés (une seule ville comptée quand un nom est partagé), donc N inter C aussi. Pour ça, voir du côté de la définition de Town.<. Manque la dernière question. |
| BERARD | Quentin | Non rendu | |
| BERKES | Valentin | 4 | Attention les valeurs des histogrammes sont faux : un nom de ville qui apparaît n fois est compté n fois au lieu de 1 fois, et idem pour les coordonnées. Bien pour le reste. |
| BLARRE | Auriane | 3.5 | Mettre le code exécutable dans des .cpp, pas dans des .h (sauf si impossible de faire autrement, p.ex. template). Attention, le code qui lançait la résolution des questions était en commentaire. Erreur dans Point2D::operator.< qui fausse les résultats de Q2, Q3, Q4. Solution de Q3 un peu compliquée, qui utilise bien set_intersection, mais qui ne calcule pas N et C le plus efficacement. Bien pour Q4. |
| BOULVARD | Pierre-Marie | 2 | C'est bien compliqué et finalement le programme n'affiche pas véritablement ce qui est demandé. |
| BUBBA | Federica | 5 | Traitement de la dernière question un peu long (on peut faire plus court) mais OK. Attention votre CMakeLists.txt ne crée pas le bon exécutable. |
| COHEN | David | 5 | TB |
| CONSTANTINI | Dan | 5 | TB |
| CRESSOT | Loïc | 4 | Sortie trop verbeuse, les histogrammes doivent indiquer seulement le nombre de villes, pas leur nom. N et C sont sous-estimés, voir pour ça du côté de la définition de « Town.< ». |
| DAYAN | Sharone | 5 | TB |
| DESCHAMPS | Sébastien | 4.5 | N et C sont sous-estimés (une seule ville comptée quand un nom est partagé), donc N inter C aussi. Pour ça, voir du côté de la définition de « Town.< ». |
| DING | Hongyang | 5 | TB |
| DRONNIER | Dylan | 5 | TB |
| DUPRE | François | 5 | TB. Fournir un CMakeLists.txt. |
| EL RHAFFOULI | Hamza | Non rendu | |
| FENG | Leman | 6 | Excellent ! |
| FLEURY | Madeline | 5 | Bien compris, bon rapport, mais solution de question 4 un peu compliquée. |
| FUJIKAKE | So | 6 | Excellent ! Va bien au delà de ce qui était demandé. |
| GILLIER | Adèle | 5 | TB |
| HAENTJENS | Guilain | Non rendu | |
| HAYAT | Tom | 5 | TB. Indiquer ce que sont les valeurs quand on les affiche (sinon on voit juste une série de chiffres). |
| JACOB | Etienne | 4.5 | Envoi incomplet (main.cpp seul, il manque town.cpp et point2D.cpp modifiés). OK sinon. |
| KABBAJ | Hamza | 3 | Fournir une archive nettoyée. Attention les valeurs des histogrammes sont faux : un nom de ville qui apparaît n fois est compté n fois au lieu de 1 fois, et idem pour les coordonnées. Q3 n'est pas résolu de la manière demandée, avec la complexité demandée. |
| LEBASTARD | Simon | Non rendu | |
| LEMAIGRE | Adrian | 4 | Pour Q3, il fallait utiliser set_intersection, de complexité linéaire, au lieu d'une méthode potentiellement quadratique. Pour Q4, l'utilisation répétée de find n'est pas très efficace (on peut aller 300 fois plus vite). |
| LINA | Adrien | 4 | Pour les histogrammes, afficher des chiffres plutôt que des séries de « # », c'est plus lisible. Pour Q4, la réponse est fausse (vous auriez pu vérifier les villes concernées!) car vous oubliez d'exclure le cas où it1->name() == it2->name() == it3->name() == it4->name(). |
| MARGHERITI | William | 5 | TB |
| MARTIN | Thomas | 1 | Nettoyer le code des affichages de debug avant de le livrer. Calcul d'histogramme très inefficace (quadratique au lieu de linéaire!) qui n'exploite les map. Calcul d'intersection très inefficace et faux. Segmentation fault pour la suite. |
| MILLET | Juliette | 5 | TB. Bon rapport. |
| OUCHTAR | Eïda | 4 | TB, dommage qu'il manque la dernière question. |
| PARAN | Arnaud | Non rendu | |
| SANH | Victor | 3.5 | N et C sont sous-estimés (une seule ville comptée quand un nom est partagé), donc N inter C aussi. Pour ça, voir du côté de la définition de « Town.< ». Manque la dernière question. |
| SOULIER | Eloïse | Non rendu | |
| TROUSSARD | Martin | Non rendu | |
| VESSAIRE | Cyrille | Non rendu | |
| ZEMMOURI | Youcef | 4 | Votre définition de == pour Point2D est correcte, ça aurait dû marcher pour le calcul d'histogramme. Dommage il manque la dernière question. |
| ZOUAKI | Laïla | 3 | OK pour le début, mais il manque les dernières questions... |