Validation d’acquis d’apprentissage en 1A #

Les travaux pratiques ne seront pas notés au sens traditionnel du terme. À la place, durant les TPs, et pour certaines questions, l’enseignant prendra connaissance du travail réalisé. Vous pourrez être amenés à expliquer pourquoi vous avez procédé de la sorte et à répondre à quelques questions.

Selon les réponses données et certains critères, votre retour participera à la validation d’acquis d’apprentissage. C’est cette grille de validation qui sera utilisée pour donner une note de TP lorsque toutes les séances seront terminées.

Liste des acquis d’apprentissage #

■ [Algo] Les étudiants seront capables, étant donné un problème relevant de l’arithmétique, du traitement des chaînes de caractères ou des listes (liste non exhaustive), de décrire en langage naturel les structures de contrôles qui seront nécessaires à la résolution du problème et leur assemblage (boucles imbriquées, boucle contenant un test, test contenant une boucle…) Le type de problème simple envisagé est par exemple : sommer les multiples de 3 et de 7 inférieurs à 1000, compter le nombre de voyelles dans un mot, rechercher les deux valeurs d’une liste qui encadrent la moyenne des éléments d’une liste d’au moins 2 éléments. Des niveaux d’acquisitions différents sont envisagés selon la complexité du problème (de 1 à 4).

Il s’agit ici d’être capable d’expliquer clairement comment fonctionne la solution qui est proposée. Noter que ce n’est pas le code proposé qui est évalué, mais l’algorithme sous-jacent donné oralement.

■ [Analyse] Les étudiants seront capables, entre deux codes différents (dont ils ne seront pas nécessairement auteurs) utilisant des structures de données standard comme les listes, les dictionnaires et des structures de contrôle (boucles) ou des appels récursifs, de choisir le code le plus efficace dans le contexte de l’exercice, sans avoir besoin de l’exécuter.

Il s’agit ici de montrer que vous savez faire la différence entre différentes versions, toutes justes, mais d’efficacité différente. Par exemple, rechercher la présence de doublons dans une liste avec deux boucles imbriquées n’est pas la solution la plus efficace. Autre exemple : pour tester si un élément est dans une collection, il vaut mieux que la collection soit un ensemble ou un dictionnaire qu’une liste ou un tuple.

■ [Erreur] Face à un code non fonctionnel contenant des erreurs de types : indentation, syntaxe, indice hors limite… qui résulte en une levée d’exception, les étudiants seront capables, en analysant le message d’erreur, et en réalisant quelques opérations de déboguage :

de circonscrire la source de l’erreur,
de la corriger (sauf si erreur de conception).

Il s’agit ici de montrer que lorsqu’un code s’arrête suite à une levée d’exception (message d’erreur), vous êtes capable d’analyser ce message, et que cette analyse vous permet de circonscrire l’erreur (pourquoi elle a lieu, et où a-t-elle lieu ?). Par ailleurs, selon le type d’erreur, il faudra être capable de la corriger et d’indiquer en quoi cette correction règle le problème.

■ [Jolicode] Les étudiants seront capables d’écrire du code répondant à divers critères de lisibilité dans le langage Python (indépendamment du fait que le code est fonctionnel ou non) :

choix corrects pour les noms de variable (the longer the scope, the longer the name, noms évocateurs donnant des indications sur l’usage de la variable) ;
découpage en plusieurs fonctions pour ne pas avoir des blocs de code trop longs, et pour pouvoir réutiliser du code ;
introduction de commentaires lorsque c’est nécessaire et uniquement lorsque c’est nécessaire.
utilisation de structures idiomatiques, réécriture du code redondant.
produire un code simple plutôt qu’un code inutilement compliqué

L’objectif est que le code produit soit de qualité pour une lecture par un humain (la relecture de code est une tâche bien plus courante que ce qu’on peut imaginer). Différents critères sont utilisés (nommage des identificateurs, utilisation de constructions appropriées, écriture de code non redondant) qui sont détaillés dans quelques documents de cours.

■ [Test] Les étudiants auront un regard critique sur les résultats obtenus :

vérification avec des procédures de test fournies,
recul par rapport à la crédibilité du résultat / écriture de tests, s’il n’y a pas de procédure de test fournie.

L’objectif est d’avoir pour réflexe de ne plus se satisfaire d’un résultat, mais d’être capable d’évaluer s’il est juste, soit en utilisant des tests fournis, soit en écrivant ses propres tests sur des cas vérifiables.

■ [Input] Les étudiants seront capables d’utiliser des données d’entrée de différentes natures dans leur code : fichier texte, fichier de données numériques, fichier image…

■ [Output] Les étudiants seront capables de produire des données de sortie sous différentes formes : affichages, fichiers contenant du texte, fichier csv, images, graphiques…

Et en pratique en TP ? #

À chaque question / exercice, terminé, vous appelez l’enseignant. S’il n’est pas disponible immédiatement, vous pouvez continuer le travail, tout en gardant la possibilité de revenir rapidement à l’exercice non validé.

Les seuls éléments qui sont pris en compte sont ceux validés par l’enseignant durant le TP, si vous êtes capables de fournir tous les éléments attendus.

Vous n’aurez pas forcément un retour immédiat sur l’exercice et sur ce qui a été validé ou non, tout simplement pour éviter la tentation de simplement répéter le discours brillant d’un.e voisin.e de TP.

Ci-dessous, les points de vigilance pour chaque TP.

TP 1 (Exercices courts) #

Ce sera presque toujours le cas : l’enseignant peut vous demander d’expliquer le fonctionnement de votre code (c’est à dire l’algorithme sous-jacent), il faut pouvoir le donner sans hésiter.
Lorsqu’une procédure de test est fournie, vous devez l’avoir utilisée lorsque vous faites valider un exercice.
Bien choisir les noms de variable : i, j, k et n sont réservés aux entiers (voire aux indices de boucle pour i et j). Écrire for i in range(len(lst)) mais pas for i in lst.
Après un if, il y a une expression booléenne. Aussi, on n’écrit pas :

if a == 3 and b > 4:
    return True
else:
    return False

mais simplement : return a == 3 and b > 4

Pour parcourir une liste, on peut faire : for i in range(len(lst)) ou bien for v in lst. La seconde option ne donne pas accès à l’indice, mais juste à la valeur, ce qui est souvent suffisant et économise une paire de crochets dans la suite du code. Si c’est possible, on fera donc un parcours sur les valeurs plutôt que sur les indices.
La structure de dictionnaire permet d’associer une valeur à une clé arbitraire (plutôt qu’à un numéro d’ordre dans le cas d’une liste). Utiliser les dictionnaires aux bons endroits permet d’avoir un code plus efficace et aussi plus clair.
Lorsqu’on énumère des cas un peu complexes, il convient de vérifier (avec un brouillon/un dessin par exemple), qu’aucun cas n’a été oublié. Par ailleurs, la traduction en code doit être la plus élégante possible (pas de répétitions, pas de cas qui se recouvrent, si c’est possible)

TP 2 (Images) #

Ce sera presque toujours le cas : l’enseignant peut vous demander d’expliquer le fonctionnement de votre code (c’est à dire l’algorithme sous-jacent), il faut pouvoir le donner sans hésiter.
Il n’y a pas de vérification automatique dans ce TP. Mais vous devez pourtant essayer de vous assurer autant que possible que le résultat est correct. Vous devez pouvoir vérifier votre code sans demander à ce qu’une tierce personne le vérifie pour vous. Montrez que vous faites ça correctement.
Si une procédure de test est suggérée, mais pas nécessairement finalisée, il faut la mettre en œuvre. Sinon, inventez une procédure de test convaincante.
Éviter de trop imbriquer de blocs. Le parcours d’une image nécessite déjà 2 boucles imbriquées. Si votre code contient 4 boucles imbriquées, c’est probablement trop, et il est sans doute souhaitable de découper en fonction.
Attention au découpage en fonctions. Si on a déjà écrit une fonction qui fait un certain travail, ne pas recommencer, mais appeler la fonction.
On rappelle que les valeurs des composantes sont des entiers entre 0 et 255. Sortir de cette plage, que ça fonctionne ou non, montre que le code n’est pas maîtrisé. Il en est de même pour les coordonnées des pixels qui doivent être dans l’images (et ne doivent pas être négatifs, même si ça marche…).

TP 3 (Crypto historique) #

Ce sera presque toujours le cas : l’enseignant peut vous demander d’expliquer le fonctionnement de votre code (c’est à dire l’algorithme sous-jacent), il faut pouvoir le donner sans hésiter.
Lorsqu’une procédure de test est fournie, vous devez l’avoir utilisée lorsque vous faites valider un exercice.
S’il n’y a pas de procédure de test fournie, il faut en inventer une, la plus complète possible.
Attention aux fonctions comme : lst.index(v) qui doivent parcourir toute la liste lst (ce n’est pas forcément grave, mais il faut en être conscient). Si on peut éviter des parcours inutiles, il faut le faire.
Attention au découpage en fonctions. Si on a déjà écrit une fonction qui fait un certain travail, ne pas recommencer, mais appeler la fonction.
La mémoire ne coûte pas cher, surtout pour les petits exercices que nous faisons. Mais c’est en étant conscient de l’impact mémoire de votre code sur des cas faciles que vous pourrez gérer des cas plus délicats. Ne gaspillez pas l’espace mémoire. Certains choix que vous avez fait pouvant être ambigus, n’hésitez pas à les justifier (ce qui pourrait être perçu comme un mauvais choix peut être reconsidéré s’il est bien justifié).

TP 4 (Dictionnaires + exos) #

Ce sera presque toujours le cas : l’enseignant peut vous demander d’expliquer le fonctionnement de votre code (c’est à dire l’algorithme sous-jacent), il faut pouvoir le donner sans hésiter.
Attention au découpage en fonctions. Si on a déjà écrit une fonction qui fait un certain travail, ne pas recommencer, mais appeler la fonction.
Il n’y a pas de vérification automatique dans la partie sur les dictionnaires. Mais vous devez pourtant essayer de vous assurer autant que possible que le résultat est correct. Vous devez pouvoir vérifier votre code sans demander à ce qu’une tierce personne le vérifie pour vous. Montrez que vous faites ça correctement.
Écrivez du code simple. Si ce que vous avez fait en 10 lignes est faisable en 2, il faut le faire en 2 (à moins qu’on perde trop en lisibilité).
Les petits exercices de la deuxième partie reprennent des thèmes déjà vus en TP. Il faut donc être vigilant sur tous les points des TPs précédents : noms de variables, type de boucle for, maîtrise de la complexité, code élégant, etc.