Le marathon de notation des rapports vient de se terminer et m'a inspiré les deux dessins ci-joints à propos du texte de la partie "analyse" (dessins dans le style de xkcd).
Concernant le pseudocode Il y avait une grande richesse de solutions qui se ramenait à 4-5 grandes familles. ça prend malgré tout du temps à vérifier. De plus j'ai vérifié que l'ordre de complexité indiqué correspondait au pseudocode.
Pour l'ordre de complexité, il fallait indiquer l'expression du terme dominant avec la notation en O( ... ) en montrant les variables impliquées telles que nbL, nbC et nbF ou nbR si nécessaire. Pour le cas de nbR j'ai accepté que cette variable soit absente de l'ordre de complexité si le texte le justifie (dans le cas où le pseudocode s'en sert, évidemment).
J'aurais aimé mettre plus de notes maximum mais trop souvent il y avait des erreurs d'étourderies dans le pseudocode que je ne pouvais pas laisser passer, par exemple:
- sur des noms de variables incorrects (ex: un nom différent dans la liste des paramètres et dans le corps de la fonction)
- expressions incorrectes avec des indices (ex: copier-coller), borne de boucle, etc
- des expressions incomplètes (oubli d'indiquer explicitement l'expression des 8 voisins pour l'initialisation d'un tableau chez quelques uns)
- première lettre en majuscule au lieu de minuscule
- oubli d'indiquer des paramètres d'une fonction
- des erreurs d'indentations qui rendent le code incorrect
- des instructions dans la mauvaise boucle
Il y avait aussi de véritables erreurs qui demandaient un peu plus de réflexion MAIS la plupart de ces erreurs auraient pu être supprimées en faisant une simple RELECTURE attentive. C'est le message principal de ce feedback.
mauvaise pratiques en termes de lisibilité:
- définir une fonction à l'intérieur d'une autre fonction. -> définir vos fonction les unes à la suite des autres.
- écrire en langage naturel -> revoir le cours ICC pour le style de pseudocode à adopter
- indentation trop faibles qui induisent en erreur
- Certains pseudocodes étaient
difficiles à lire parce que c'étaient du C++ retraduit en français, ou
même écrit tel quel (push_back). Dans ce projet les dimensions des
tableaux d'images sont connues ; le pseudocode peut donc indiquer
directement les tableaux avec leurs dimensions en fonction de nbL, nbC,
nbR, ou 8. Construire un tabeau dynamique avec des séries de push_back()
est de toute façon moins performant que de le déclarer en une seule
fois avec sa taille si elle est connue dès le début (voir cours sur ce
sujet).
J'ai seulement vu 2 ou 3 projets où l'analyse des 8 voisins justifiait vraiment une approche purement "dynamique", c'est à dire en partant d'un tableau vide auquel on ajoute un élément en fonction de ce qu'on trouve pami les voisins.
----------------------------------------------------------------------------------------
Les notes sont sur moodle, à coté des autres fichier pdf de notes partielles:
https://moodlearchive.epfl.ch/2018-2019/mod/resource/view.php?id=1008357
--------------------------------------------------------------------------------------------
Comme pour les copies d'examen, je dois archiver les rapports mais il est possible de demander à consulter votre rapport en
prenant un rendez-vous individuel avec ma secrétaire Mme
Claire-Lise Coscia qui les conserve.
Mme Coscia travaille le lundi toute la journée et le mercredi matin, email: claire-lise.coscia@epfl.ch.
