Indication des critères de correction
  pour une meilleure compréhension
  de la note associée aux projets
  de l'option   "Probabilités et Statistiques"
  en Licence Informatique
 

     (gH) gilles.hunault@univ-angers.fr  

Ce texte, relativement détaillé, est mis à la disposition des étudiants et étudiantes de Licence Informatique, qui, ayant écrit un programme informatique qui fonctionne à peu près ne comprennent pas pourquoi ils ou elles n'ont pourtant pas la moyenne... alors que, comme indiqué, la partie programmation ne compte que pour 25 % de la note, soit au maximum 5 points sur 20 -- ceci est bien sur un exemple de phrase trop longue, avec trop de subordonnées relatives, donnant trop d'idées à la fois, ce qui fait qu'on se perd dans sa lecture et qu'il faut donc l'éviter (remarque : ce n'est pas la lecture de ce document qu'il faut éviter mais l'écriture de telles phrases !). La plupart de ces remarques font appel au bon sens et sont liées à un respect strict des consignes du projet. D'autres remarques font appel à l'intelligence, à une certaine sensibilité quant à des notions quasi-subjectives comme la lisibilité. Enfin, nombre de ces remarques sont "évidentes" mais ce qui est "évident" pour certain[e]s ne l'est visiblement pas pour d'autres... Ces remarques ont pour but de montrer dans quel esprit a été faite la correction. En principe, elles doivent lever toute ambiguité sur ce qu'il fait faire et ne pas faire, et en particulier ce qu'il faut dire et ne pas dire dans la rédaction... Ce texte a été initialement écrit pour le projet 2003/2004 où il fallait programmer la détermination d'un nombre minimum de mots ayant un même score dans la partie probabilités et l'analyse de la variance à un facteur dans la partie statistiques. Toutefois les conseils restent valables pour les autres années. On pourra consulter avec profit le détail des commentaires liés à chaque projet dont le lien est donné à la fin de ce fichier (l'ordre et les noms de fichiers ont été changés pour respecter l'anonymat).

 

1. Consigne de base : archive et noms de fichiers

La première chose à comprendre est qu'il y a des consignes à respecter. Ces consignes ont pour but de "cadrer" les noms de fichiers, les formats d'archives, la récupération automatique des fichiers à partir des mails envoyés. Une consigne sur la page 1 de l'énoncé du projet dit Cette archive, unique, sera au format zip ou tar. Cette consigne signifie que les formats autres (comme rar, ror, sit, hqx...) ne sont pas autorisés. Pourtant, le correcteur en a reçu ! Le format zip ou tar est obligatoire pour que la procédure appelée par le procmail puisse extraire l'archive du message puis qu'elle puisse en extraire les fichiers... Si ce format n'est pas respecté, le commentaire de correction est Format XXX non reconnu. Projet non évalué. Note : 0. Le projet n'est donc pas évalué et la note est 0, jusqu'à réception d'une archive au bon format. Le mot unique de la consigne demande des explications. D'abord cela signifie qu'il faut utiliser une seule archive, c'est à dire un seul nom de fichier, même en cas d'envois multiples. La procédure de récupération décompresse en prenant la dernière version (dernière au sens de la date et heure de sauvegarde) des fichiers. Comme il est indiqué dans l'énoncé, au bas de la page 1, le nom de l'archive doit commencer par les initiales correspondant au document signé en TD. Il est donc possible d'envoyer, disons si nos initiales sont AAA, une archive nommée AAA_projet.zip ou AAA.ZIP mais il est interdit d'envoyer les deux. Si on a commencé avec AAA_projet.zip, il faut, lors d'un autre envoi, réutiliser le même nom, et surtout pas AAA2.ZIP ni AAA_projet_version2.zip. La même consigne s'applique aux fichiers contenus dans l'archive. La page 8 du projet indique Tout fichier qui ne correspondra pas aux initiales de l'élève ne sera pas lu. En particulier, les fichiers nommés uniquement proba, algo, stat, projet, doc ne seront pas lus. La raison en est simple : la procédure qui décompresse les fichiers de l'archive le fait automatiquement. Si un fichier nommé par exemple dossier.doc existe, elle l'écrase... dès qu'elle décompresse une autre archive contenant un autre fichier nommé dossier.doc. Lorsqu'à la date limite le correcteur transfère les fichiers, il n'a aucune idée de ce qui s'est passé. Ayant reçu une liste qui donne le nom des fichiers zip et tar, le correcteur traite les fichiers de même nom. Si AAA.ZIP est dans la liste, il cherche donc tous les fichiers nommés AAA* (sous Unix) ou AAA*.* (sous Windows). Il n'a donc aucun moyen de relier un quelconque fichier nommé projet.pas à AAA.ZIP... Si cette consigne n'est pas respectée, le commentaire de correction est Aucun fichier AAA*.* n'est présent dans l'archive. Le projet n'est pas noté. A renvoyer. Note : 0. et la note est 0 jusqu'à réception d'une archive avec des fichiers correctement nommés.

 

2. Rédaction : titre et orthographe

La deuxième chose à comprendre est que le travail demandé est d'abord un travail de rédaction. La page 1 du document à rendre doit donc comporter un titre, un nom d'auteur. Sinon, à qui attribuer la note ? C'est pourquoi tous ceux et celles qui n'ont pas écrit leur nom et leur prénom ont droit au commentaire : Aucun nom d'auteur, mais qui est-ce donc ? Par contre, le choix d'un titre court, en haut de la page 1 ou l'écriture d'une page complètre de titre, avec logo, date, lieu... est laissé à l'appréciation de l'auteur du document, de même que l'écriture d'une table des matières ou d'un plan. Ecrire un document, c'est faire oeuvre de communication. Personne n'est parfait et une faute de frappe est si vite arrivée, il est si facile d'oublier un mot lorsqu'on pense plus au fond qu'à la forme qu'il est obligatoire de faire relire son documen par quelqu'un d'autre (avez-vous vu qu'il manque un "t" au mot document précédent ?). Si le correcteur orthographique et grammatical de Word (ou de Latex) voit certaines fautes flagrantes, il ne les détecte pas toutes. Et il ne dira pas : "cette phrase est incompréhensible". Donc faites relire. Arrivé(e) à plus de 20 ans et en Licence, c'est à dire en Bac+3, il n'est pas possible de laisser dans un document des fautes aussi énormes que controle continue programme principale les variable est on ce rend compte l'algorithme fournit est etc. Corriger l'orthographe est une obligation, quelque soit le niveau de l'auteur. Cela prouve au moins qu'on a relu, qu'on a fait relire et que ce n'est pas le dernier jour, à la dernière minute qu'on écrit le texte, vite fait, sans réfléchir... sans relire. Si on peut être un peu plus tolérant pour les personnes étrangères dont la langue maternelle n'est pas le français, on ne peut pas accepter des fautes élémentaires pour des gens sachant accorder les articles et les noms depuis plus de 15 ans...

 

3. Méthode, algorithme et programme

Rédiger est un art, expliquer comment on a programmé est souvent difficile, mais non impossible. Il y a certaines règles de base à respecter pour que le texte rédigé soit lisible et compréhensible. Pour que la rédaction soit agréable et lisible, il faut faire des phrases courtes. Le modèle standard "sujet, verbe, complément" est le meilleur garant de concision et de clarté. Ecrire On utilise un tableau de points qu'on initialise avec le tableau des points précédents mais si, en fonction des groupes de codes utilisés ensemble, on trouve déjà les points recherchés alors, d'abord, si on n'a pas encore d'exemple, on le rentre pour le garder quand même, afin de calculer le nombre de codes possibles qu'on additionne au résultat, précédemment trouvé mais non initialement égal à 0 si c'est pour un nombre plus grand que deux car on a déjà commencé à le calculer. est forcément source de confusion. Attention : il faut bien comprendre que rédiger des explications sur la méthode, sur l'algorithme et le programme sont trois choses différentes. 3.1 Rédiger la description de la méthode La méthode doit être compréhensible par n'importe quel étudiant de deuxième année de Deug, maths ou info, ou par toute personne de bonne volonté. La méthode est la transcription en phrases du résultat de la partie "analyse" du projet. La méthode décrit la version finale du projet, pas les divers essais ratés, complétés, modifiés. Il ne faut pas détailler l'historique du projet, il faut seulement rédiger la version que vous avez implémentée et retenue. La description de la méthode utilise des mots simples, donne des exemples (numériques ou chaines) et des graphiques, des dessins avec de flèches si besoin est. Elle se veut claire et n'importe qui devrait être capable en lisant la méthode d'indiquer ce fait en gros le programme, dans quel ordre il se déroule, comment les tableaux sont remplis, ce que le programme fait a l'étape 1, après 3 appels de boucles, etc. La description de la méthode repose sur donc l'affichage de parties de tableaux, sur des exemples de calculs détaillés. Au niveau de la méthode, on ne doit utiliser aucune déclaration informatique empruntée au C, au Pascal ou à Java. On ne doit pas y faire référence à des pointeurs, des enregistrements, des structures. On n'y dispose que de deux types (concrets) de données : les variables simples et les tableaux car on veut que ce soit compréhensible par tous et par toutes. On ne vient donc pas sans s'y encombrer de considération de taille mémoire, d'indice commencant à 0, de chaine se terminant par "\0" ou autre bricolage non humain. C'est à partir des exemples qu'on introduit le nom des variables, des tableaux. Grace aux exemples, on est à même de dire si les tableaux utilisent 1 ou 2 (ou plus) indices. Ces indices sont explicités en terme de rang, de position. Comme ils s'adressent à des êtres humains, on peut ignorer les subtilités liées aux pointeurs, aux implémentations et aux références, aux adresses. Les tableaux utilisés dans une méthode commencent donc toujours à 1. Lorsqu'on utilise plusieurs indices, il faut dire à quoi correspondent les lignes et les colonnes des tableaux. Par exemple si on a des valeurs à mettre pour des facteurs et des groupes, parler de tabVal[ indi ,indij ] ne dit pas si indi correspond à un groupe ou à facteur, parler juste après de moyGrp[ indk ] ne dit pas facilement comment relier indk à indi ou à indj. Après avoir effectué la lecture de la méthode, on doit être capable de répondre à la question que contient monTab[ indi, indk ] ? à l'aide d'une phrase comme il s'agit d'un score (d'un mot, d'une moyenne...) calculé pour les mots (les données, les facteurs) de longeur indi (de taille indi, en dimension indi) pour le critére de constraste numéro indk (pour la colonne indk, pour les exemples de score indk...). En général, pour décrire la méthode on utilise des termes comme "parcours", "passage en revue", "recherche de...", ces actions étant liées à des "groupes", "listes", "ensembles" de données ou de valeurs. Il ne s'agit pourtant pas de "vraies" listes, groupes ou ensembles au sens mathématique ou informatique du terme mais cela ne prête pas à confusion en général... car le recul induit par la rédaction est là pour guider la compréhension. Si par contre on uilise des termes précis comme "arrangement", "combinaison", "vecteur", on prendra soin d'indiquer si ce sont ceux des mathématiques ou du sens commun... C'est au niveau de la méthode qu'on expose les bornes des parcours, des boucles liées au sujet, qu'on les démontre. Mettre dans un algorithme une boucle pour indScor de 3 à 87 est acceptable si dans la méthode on a exposé d'où viennent le 3 et le 87. D'ailleurs pour la partie probabilité (projet 2003/2004), le score maximal est 85 selon les uns, 86 voire 87 pour les autres. Il n'est pas possible d'escamoter d'où vient cette valeur. Et seul un calcul expliqué à partir de 5*17 ou 3x22+15+5 peut montrer quelle est la bonne réponse... Pour bien rédiger la méthode, il faut impérativement s'affranchir des langages de programmation et de la machine, prendre du recul et surtout, ne pas écrire des incongruités (pour un être humain) comme on utilise un tableau monT_Mot = (char *) malloc (nblettre * sizeof (char)); 3.2 Rédiger la description de l'algorithme Pour décrire l'algorithme, il faut se souvenir qu'il y a deux types de commentaires, de description. Les commentaires de type 1 sont les commentaires "en ligne", écrits à l'intérieur de l'algorithme. Ils sont soit forcés, obligatoires et peu intéressants (pour un humain) comme fin_pour # indi de1a nbMots - 1 soit plus généraux et servant de repère comme # étape 1 / 3 : recherche du minimum de... ou encore # on peut se contenter de commencer à l'indice 4 # car l'analyse a montré que pour une taille inférieure # ou égale à 3, il n'y a aucun... affecter valInd <-- 4 tant_que valInd <= nbLet - 2 Les commentaires de type 2 sont les commentaires "hors ligne", écrits séparément (c'est à dire dans un autre document, un autre fichier que l'algorithme). Ce sont ces commentaires que vous devez mettre dans la rédaction qui vous est demandée. Donc, en insistant sur ce point : ce ce qu'on doit rédiger ce n'est pas ce qui est mis comme commentaire "en ligne" dans le texte de l'algorithme. Le but de ces commentaires de type 2 est de dégager les parties majeures de l'algorithme, sans avoir à parcourir tout le listing fourni par Galg, ou sans avoir à se dire "mais quel fichier .alg faut-il lire en premier, en deuxième... ?". La rédaction de l'algorithme doit être cohérente avec l'analyse et complémentaire de cette analyse. Elle reprend les parcours et vient les nommer, indique où ils sont, si on en fait des boucles dans l'algorithme principal ou si onles appelle via des sous-algorithmes. Cette rédaction vient "bien sûr" présenter les instructions importantes et non pas toutes les affectations et autres "bricoles". Si vous ne savez pas quelles instructions sont importantes, ayez recours à Galg. L'utilisation du listing fourni par Galg avec les indications de ligne, d'instruction, de profondeur d'imbrication permet de voir tout de suite quelles instructions décrire. A savoir : au moins celles qui commencent un nouveau numéro d'instruction et qui incluent un changement de niveau d'imbrication. Ainsi, lorsqu'on voit une partie de listing galg comme 076 | 010 001 tant_que (non endi) 077 | 078 | 010 002 si (nbLettres<=2) 079 | 010 002 alors # 080 | 010 002 affecter resultat <-- computeScor(tcod) 081 | 010 002 affecter tScort[resultat] <-- scores[resultat]+1 082 | 010 002 affecter indk <-- strcmp(samples[resultat], "") 083 | 084 | 010 002 appeler _affecterChaine(samples[resultat], tcod) 085 | 086 | 087 | 088 | 010 002 affecter stopper <-- ... 089 | 010 002 sinon 090 | 010 002 affecter lecar <-- "A" 091 | 010 002 affecter stopper <-- FALSE 092 | 010 002 fin_si # nbLettres<=2 093 | 094 | # Cette boucle fait varier tous les les... 095 | # On utilise un ordre différent si... 096 | # (en ne tenant pas compte du premier et du ... 097 | # Au passage, on calcule le nombre d'occurrences de... 098 | # Exemple : 099 | # .AAA., .BAA. -> .ZAA., .BBA. -> .ZBA. -> .ZZA.... 100 | 101 | 010 002 tant_que (non stopper) 102 | # Etape 1 : On calcule de A -> Z ou de B -> Z ou ... 103 | 010 003 pour j de lecar à "Z" 104 | 010 003 affecter tcod[1] <-- j 105 | 010 003 affecter resultat <-- computeScor(tcod) 106 | # Puis on calcule son... 107 | 010 003 affecter tScort[resultat] <-- sScort[resultat] +... 108 | # Et on donne un exemple de tcod au score 109 | 010 003 affecter indk <-- strcmp(samples[resultat], "") 110 | 111 | 010 003 appeler _affecterChaine(samples[resultat], tcod) 112 | 010 003 fin_pour # j de lecar à Z 113 | 114 | # Etape 2 : ensuite on recherche le... 115 | # exemple : si tcod=.ZAA. alors indice=2 à la fin de la recherche 116 | # si tcod=.ZZA. alors indice=3 à la fin de la recherche 117 | 010 002 affecter indice <-- 2 118 | 119 | # 120 | 010 002 affecter indk <-- tcod[indice] 121 | 010 003 tant_que (indk=90) et (indice on peut croire que les choses sont compliquées (car en plus l'algorithme est mal indenté). Mais en fait galg dit qu'il n'y a qu'une instruction, l'instruction numéro 10 et qu'il s'agit d'une boucle tant que. Pour ne pas inclure ce listing dans la rédaction, car ce serait alourdir inutilement la rédaction, on pourra dire le parcours de recherche présenté dans la méthode est implémenté par une boucle tant_que (voir les lignes 76 à 167 du listing) qui permet de calculer le... tant que le test de... n'est pas fini. Aprés un test élémentaire sur le nombre de lettres (lignes 78 à 92), on remplit le mot-exemple grâce aux trois étapes de la méthode... Décrire un algorithme, ce n'est pas donner la liste des fonctions, sous-programmes et sous-algorithmes ou autres modules. Donner la liste des fonctions n'explique pas comment on les utilise, où on les appelle. Si on écrit fonction rechercheScore fonction rechercheMot Il y a plusieurs façons d'utiliser ces sous-algorithmes. Ce peut être une simple succession d'appels, comme APPELER rechercheScore APPELER rechercheMot Mais ce peut-être plus compliqué, avec des imbrications comme tant que indi<38 APPELER rechercheScore si longueur(motXmp)>0 alors APPELER rechercheMot ... ou encore autre chose. Le critère d'une bonne rédaction pour un algorithme, c'est que son explication des grandes étapes permet de regarder le listing de Galg en diagonale, en s'arretant à peine sur chaque nouvelle instruction. Imaginez-vous en train de lire la description d'un algorihtme et que vous trouviez seulement la liste suivante : fonction testC1 : regarde si la matrice est symétrique fonction diagT : renvoie la diagonale de la matrice foncion buneman : teste si la condition de buneman est vérifiée pouvez-vous alors dire ce que fait l'algorithme et dans quel ordre on utilise les sous-programmes ? C'est pour cela qu'il faut faire relire votre document car un auteur est toujours capable de relire lui-même... à jeun et à moins de six mois d'intervalle entre deux lectures... 3.2 Rédiger la description du programme Contrairement à ce demandent d'autres enseignants, cette partie est facultative pour le correcteur et auteur de ce document car cette partie est relativement "bête", presque mécanique. On peut donc l'omettre. Si l'algorithme est propre, la traduction et l'adaptation ne présentent pas de difficultés majeures. On se doute bien qu'en Licence Informatique vous savez traduire les pour en for et éventuellement remplacer tabMots[ indi ] par tabMots[ ++indi ] si vous voulez commencer à utiliser l'indice 0 du C (ce qui n'est pas obligatoire car on peut aussi augmenter de 1 la taille du tableau et ne rien changer...). De plus un programme n'est pas écrit pour un être humain mais pour une machine, donc pourquoi le lire ? Au rique de faire une répétition, le programme en tant que tel n'intéresse pas le correcteur. Il doit être présent, comme dans tout travail de programmation, suivant le cycle : analyse, rédaction de la méthode, algorithme, programme, jeux d'essais, rédaction de l'ensemble du projet. Il doit être cohérent avec l'algorithme (sans en être forcément la traduction par Galg), disponible sous forme de source et prêt à l'emploi sous forme d'exécutable.

 

4. Quelles sont les erreurs à éviter dans la rédaction ?

On trouvera ici un "pot-pourri" des erreurs les plus fréquentes rencontrées dans les rédactions des projets. Il est impératif de lire cette section pour éviter de se faire "déchirer" comme disent "les jeunes" lors de la seconde correction pour ceux et celles qui font un nouvel envoi. Le correcteur n'a évidemment aucun grief particulier contre les auteurs des projets. Il présente ses excuses à toute personne se sentant personnellement impliquée par une correction particulière où la "stupidité" de la rédaction est flagrante. Il demande aussi à ceux qui ont la moyenne de l'excuser d'insister sur des évidences aussi fondamentales... L'erreur la plus flagrante et qui mérite d'être en tête et à part est la suivante NE PAS AVOIR FAIT RELIRE SON DOCUMENT PAR QUELQU'UN D'AUTRE Choisissez bien cette autre personne : il faut quelqu'un qui vous aime bien mais qui n'hésite pas à vous dire "là c'est une faute d'orthographe", "là c'est un peu confus", "là c'est trop fouillis"... Relisez par exemple les projets et les programmes des autres étudiant[e]s de la promotion, et faites-leur relire vos textes. Vous avez le droit (puisque le le correcteur vous le dit), ce n'est ni de l'espionnage, ni du copiage. Même si (et c'est aussi autorisé) vous avez réfléchi à plusieurs ou travaillé à plusieurs, les explications ne seront pas exactement les mêmes, les phrases d'explication seront différentes... On est souvent plus critique à l'égard des textes des autres que de ses propres textes. Donc relisez leurs textes, faites relire vos textes et modifiez votre rédaction en conséquence. Vous trouverez peut-être de nouvelles idées, vous comprendrez peut-être mieux pourquoi ce que vous vouliez dire n'a pas été compris. Donc en insistant une dernière fois : faire relire et critiquer votre document. Voici les autres erreurs : 4.1 Ne pas se présenter en début de document Le document doit comporter un titre et un nom d'auteur en haut de la page 1. 4.2 Etre personnel(le), raconter sa vie On ne doit pas écrire (texte à peine modifié trouvé dans un des projets) j'ai essayé de faire un programme puis j'ai été voir ma grand-mère puis j'ai modifié le programme... mais ça marchait pas alors j'ai programmé autrement. Vous devez rédiger ce que finalement vous avez programmé. Pas vos essais, vos états d'âme, vos aventures ou vos démélés avec la complexité exponentielle du sujet ou le compilateur gcc sous Linux. 4.3 Donner son avis au lieu de rester dans l'objectivité scientifique. Si on vous pose la question "les filles portent-elles des pantalons en France ?", vous devez répondre "oui". Répondre "elles ne le devraient pas..." c'est donner son avis, ce n'est pas indiquer la pratique féminine. Si vous dites "je ne le pense pas", c'est incorrect aussi. On ne vous demande pas votre sentiment sur la question. A la question "les entreprises utilisent-elles..." vous devez répondre de même. Votre avis sur la question, sur ce que doivent ou devraient faire les entreprises, sur ce que vous en pensez n'intéresse pas le correcteur. Seule la pratique des entreprises et par ricochet ce que vous en connaissez l'intéresse... 4.4 Confondre définir, désigner, nommer, déclarer et typer Dire j'utilise un tableau pour stocker des valeurs est un truisme, c'est à dire une vérité aussi évidente que banale. Dites plutôt j'utilise le tableau valScor pour stocker les scores où valScor[ longi ] contient la valeur du meilleur score pour les mots de longueur longi. Cette phrase nomme le tableau, c'est à dire lui donne un nom. C'est suffisant au niveau de l'analyse, donc de la méthode. Au niveau de la méthode, nous n'avez pas à donner à ce tableau un type "barbare" particulier, pour en faire un array[1..XXX] of YYY ou un typedef char XXXX[250] car le typage sert à définir une implémentation en machine, à imposer des plages de variation ou à définir des zones mémoires. Cela ne sert à rien pour la compréhension de la méthode. Déclarer le tableau, c'est mettre dans le programme une instruction qui dit "là, j'ai besoin d'un tableau nommé TTTT et de type UUUU". Là encore, cela ne sert à rien pour la compréhension de la méthode. Typer, déclarer, cela ne doit apparaitre que dans le programme, nulle part ailleurs. 4.5 Confondre immodestement dire et démontrer Il n'est pas acceptable de dire en Licence Informatique Il n'y a pas de formule mathématique correspondant au problème. sous prétexte que vous n'en avez pas trouvé ou que vous trouvez le problème trop compliqué, trop paramétrique. Un peu de modestie, que diable. Dites "je n'en ai pas trouvé -- et les autres de la promotion non plus" si c'est le cas. Si par contre vous dites "la formule est", il faut en faire la démonstration. Sinon, contentez-vous de dire "elle doit ressembler à", "ce doit être...". Il faut se rappeler que l'indicatif présent est le temps de la réalité, le conditionnel celui des suppositions, de l'hypothétique... Choisir le temps des verbes est donc important suivant ce qu'on veut dire... La même remarque s'applique à ceux et celles qui osent écrire directement Il faudrait dans ce cas utiliser les contrastes de Scheffé ou les contrastes orthogonaux. Dire cela dans votre texte, c'est faire croire que vous comprenez ce que vous dites, alors que vous avez seulement recopié un texte sans doute trouvé sur le Web. Si vous voulez utiliser une remarque importante, faites une citation. Sinon, le correcteur est capable de vous demander : "D'accord. Mais pouvez-vous m'expliquer cette méthode des contrastes ?". Et là, votre réponse risque d'être embarassée.. 4.6 Ecrire n'importe quoi pour "faire" des pages Il ne faut pas inclure le texte complet des algorithmes dans le document pour faire croire qu'il y a beaucoup de pages... Il ne faut pas écrire des périphrases qui sont des parapahrases creuses comme # on additionne la colonne 1 et la colonne 2 col[ 1 ] <-- col[ 1 ] + col[ 2 ] Si vous décidez de commenter cette instruction, il ne faut pas parler d'addition mais de mise à jour ou de cumul. Il faut revenir à la définition et à la désignation des colonnes pour dire plutot # on cumule en colonne 1 (les scores) les valeurs précédentes (colonne 1) # et les nouvelles valeurs (colonne 2) 4.7 Ecrire des explications si simplistes qu'elles ne disent rien Ecrire fonction sdv : on utilise une simple boucle pour calculer la somme des valeurs. est un peu trop rapide. Une rédaction plus soignée doit plutot ressembler à Le calcul de la somme des valeurs de la colonne numéro k se fait à l'aide de la fonction sdv. Cette fonction utilise un seul paramètre, le numéro de la colonne car les données sont stockées dans la variable globale tabData. . Elle se réduit à une simple boucle pour (ligne XXXX du listing) dont l'indice varie de 1 à n (où n correspond au nombre de lignes du tableau des données). Cette fonction est appelée une fois dans le programme principal... et une fois pour chaque appel de la fonction.. quand on veut calculer... La même idée s'applique à la rédaction fonction sdc : même chose que sdv. fonction sdc : même calcul que la formule (sic). Dites plutot : (après avoir décrit en détail la fonction sdv) La fonction sdc qui calcule la somme des carrés utilise une boucle identique à celle de la fonction sdv. Sauf qu'on remplace le terme courant valData par son carré (ligne YYYY du listing). Elle est utilisée aux mêmes endroits que sdv car à chaque fois qu'on calcule la moyenne (donc la somme) on calcule la variance (donc la somme des carrés). 4.8 Erreur simples (en vrac) à ne pas commettre Mettre du code C, Pascal, Java... dans les descriptions de méthodes, d'algorithmes et les explications "hors ligne". Nommer .exe les exécutables Linux car cela ne peut que "planter" la machine pour un utilisateur Windows qui croira voir un fichier exécutable.. Demander une valeur pour sortir du programme ; même les étudiants de Deug première année n'osent plus le faire dès le deuxième TP de Pascal... Utiliser gotoxy ou équivalent pour bien afficher car la redirection des résultats avec le caractère > est alors impossible (Vous imaginez que l'imprimante va faire des gotoxy et faire remonter le papier ?). gotoxy sert plutot pour les dessins, ou pour les affichages en continu. Ne pas utiliser la notion de paramètre du programme (paramcount, paramstr en Pascal ou argc, argv en C) alors que c'était demandé. Ne pas répondre à toutes les questions en disant qu'on n'a pas eu le temps. Ne pas répondre à toutes les questions (ce n'est pas la même chose qu'au-dessus). Dire que les logiciels statistiques utilisés donnent la même valeur que l'énoncé ou prétendre avoir utilisé un logiciel statistique sans en fournir les résultats ou une copie d'écran : il y avait une erreur voulue (et évidente !) dans l'énoncé qu'il fallait signaler et qu'on pouvait détecter grâce aux logiciels. Ne pas respecter la consigne "vous utiliserez systématiquement au moins 4 lettres par identificateur". Croire qu'il s'agissait d'un projet de programmation alors qu'il s'agit d'un projet de probabilités et statistiques Ne pas tenir compte des remarques fournies lors de la pré-correction pour ceux et celles qui ont rendu le projet une semaine avant la date limite.

 

5. Notes et commentaires imprimés

Comme indiqué précédemment, l'ordre et les noms de fichiers ont été changés pour respecter l'anonymat. Les notes on été ausi été modifiées pour ne pas permettre une identification du dossier. Voici un extrait du listing des notes détaillées (éventuellement fausses pour ne pas permettre une identification du dossier) Notes pour le projet Licence Info ----------------------------------- Partie probabilités Partie statistiques Note Algo Doc Prog Quest. Algo Doc Prog Quest. / 20 / 3 / 3 / 2 / 1.5 / 3 / 3 /2 /2.5 ***.ZIP 00 ***.ZIP 00 ***.ZIP 02.5 1 0.5 0 1 0.5 1.5 0 0 ***.ZIP 03 0.5 1 0.5 0.5 0.5 0.5 0 0.5 ***.ZIP 04 1 0.5 1 0.5 0 0 1 0 ***.ZIP 05.5 0 1 1 1.5 0 0 1 1 ***.ZIP 07.5 1 1 1 0.5 1 1 1 1 ***.ZIP 10 1 1 1 1 1 1 2 2 ***.ZIP 13 2.5 2.5 2 1 0 1 2 2 ***.ZIP 15.5 1.5 2.5 2 1.5 2.5 3 1.5 2.5 Le texte complet des commentaires est ici.