Cette fiche porte sur le « Cahier d’activités algorithmiques » pour la classe de seconde.
Cette humble critique n’est pas la première qui ait pour cible la collection Odyssée. Il y a déjà deux ans, je critiquais la page 60 du manuel de première S, et tout au long de l’année scolaire 2012/2013, j’ai accumulé des remarques sur le manuel de terminale S.
C’est au tour de ce cahier d’activités en algorithmique. Certaines remarques
seront considérées comme des erreurs et signalées par le symbole !!!
.
Je voudrais tout d’abord saluer la direction et les auteurs de cet ouvrage. Même si cette page contient une majorité de remarques négatives, ce cahier est une excellente initiative, est le fruit d’un travail considérable, et est globalement satisfaisant, si on a connaissance de cette page bien sûr !
Je trouve dommage que rien ne soit dit sur la version de Python utilisée dans le cahier. Certains programmes Python sont clairement incompatibles avec Python3 (je les signalerai au fur et à mesure).
D’autre part, des conventions « officielles » existent pour le code Python (voir cette section du mémo Python sur ce site), et elles ne sont pas respectées. Je veux bien sûr parler des conventions élémentaires comme :
Je résume :
Quelques algorithmes vus au collège :
- opératoires :
- division euclidienne
- fractions
- algorithme d’Euclide
- enchaînement d’opérations
- constructions géométriques
Les exercices sont classés suivant les trois grandes parties du programme : fonctions, géométrie et statistiques. Sont précisés pour chacun :
- les prérequis mathématiques « volontairement restreints&nbps;»,
- les compétences algorithmiques mises en jeu.
Ma remarque : On note la mise en avant de Python, au côté de Scilab et Xcas, en tant que langages dont la « syntaxe est particulièrement simple et intuitive ».
Les huit premières pages sont consacrées à une « initiation à l’algorithmique ».
Page 3.
À la toute fin de la page, j’aurais ajouté « Avancer jusqu’à votre point de départ. ».
Page 4.
!!!
Je trouve que la « définition » d’un langage de programmation
n’est pas satisfaisante :
[…] un langage plus précis adapté aux instructions utilisées : on parle alors de langage de programmation.
D’une part le langage naturel, ou pseudo-code, doit de toutes façons être totalement précis, et d’autre part, aucune référence n’est faite à la mise en place de l’algorithme sur une machine.
Ce langage en mérite bien une.
Page 5.
Sans rajouter un paragraphe sur ce concept, une phrase aurait été la bienvenue, surtout qu’une phrase y conduisant est déjà toute prête ! Aussi, ça aurait été peut-être le moment de parler d’expression.
!!!
Je m’interroge sur la pertinence d’une variable qui contiendrait un
graphique, surtout en seconde.
« A prend la valeur 3. » aurait pu s’écrire : « A prend la valeur 3. »
!!!
Dans le tableau de suivi de variables, le « -5 » devrait
plutôt être un « 4 »
Une remarque que je trouve très importante dans un contexte mathématique (l’enseignant est ici un professeur de mathématiques, si tout se passe bien), est la différentiation entre le symbole de l’égalité « = » et le symbole de l’affectation « = ».
Voir la section correspondante dans un cours publié sur ce site même.
!!!
La correction de l’application 3 n’est pas correcte, car la consigne est
de renvoyer.
Ou plutôt, comme les « fonctions » sont vues plus loin, je suppose que la consigne aurait du être « qui affiche… ».
Trois autres problèmes, cette fois-ci dans la correction de cette application, dont deux dans la seule dernière ligne :
1) Pourquoi utiliser un mot français pour la sortie des résultats mais un mot anglais pour l’entrée des données ? Le mélange des genres :
peut être déconcertant.
2) La correction semble être rédigée en Python2 car en Python3, on a
besoin de convertir la sortie de input("a= ")
en entier :
int(input("a= "))
.
3) L’affichage du triplet peut troubler les élèves. Autant simplement afficher les trois nombres les uns après les autres, avec le nom de la variable :
print("a=", a)
print("b=", b)
print("c=", c)
Page 6.
Il aurait été intéressant, mais le manque de place a peut-être eu le dernier mot, d’inclure $< > \le \ge = \neq$ dans le tableau récapitulatif, et de renvoyer les lecteurs vers celui-ci depuis ce paragraphe.
Quasiment tous les langages utilisent respectivement <
, >
, <=
, >=
, =
et !=
.
L’apparition d’une fonction (à la fois mathématique et informatique) à ce moment de l’ouvrage me trouble.
D’une part les fonctions informatiques sont vues plus tard dans cette introduction, et d’autre part, si le professeur veut commencer l’utilisation de ce cahier dès le début de l’année, les fonctions mathématiques sont encore peut-être fragiles dans la tête des élèves. La fonction valeur absolue aurait sans doute suffit.
Sous le tableau contenant des implémentations de la suite de Syracuse, on trouve :
* En Python,
a % 2
désigne le reste de la division euclidienne…
Sauf que l’on ne trouve pas d’autre astérisque dans la page que le caractère utilisé pour la multiplication.
De plus, %
n’est pas utilisé qu’en Python pour le reste de la division
euclidienne. Quasiment tous les langages l’ont adopté, si jamais ils ont un
opérateur pour cela (ce que TI BASIC ne semble pas posséder).
On peut ajouter aussi (si on a de la place), que TI BASIC affiche le résultat du dernier calcul. C’est pour cela que le dernier programme ne contient pas d’instruction pour afficher à l’écran.
Page 7.
Cette formulation me semble vague. J’aurais préféré « correspondant ».
Afin d’enfoncer le clou, on aurait pu ajouter aux paragraphes de définition :
Et le programme recommence à exécuter ces instructions, tant que la condition est vraie, donc jusqu’à ce que elle soit fausse.
!!!
Le programme affiche aussi l’entier correspondant. On aurait pu
dire :
…affiche les entiers de 1 à 20 avec leur carré et leur cube.
L’usage de l’affectation multiple me semble abusif ici.
D’une part il n’est pas possible dans d’autres langages, donc autant l’éviter au lycée, sauf cas exceptionnel comme les coordonnées.
D’autre part, les rôles de a
et b
d’un côté, et de c
d’un autre sont
totalement différents (termes et compteur).
en Python3, n
sera une chaîne de caractères, et en Python2, des tuples seront
affichés.
Page 8.
L’exercice est très intéressant. Les élèves seront amusés par la génération de texte à caractère graphique, sinon artistique, et le contenu algorithmique, voire mathématique est conséquent.
!!!
Mais :
*
pour la création des chaînes (répétition d’un motif) relève
d’un sadisme total.'chaine' * 2
vaut en effet chainechaine
, 'chaine' * 3
vaut
chainechainechaine
(pour les fans d’Aretha),print('*', end='')
pour afficher une astérisque sans
passer à la ligne,print()
pour passer à la ligne,La deuxième remarque est très pertinente, et on peut ajouter :
ce qui peut être très maladroit si on utilise une boucle itérative.
Page 9. Beaucoup de choses à dire ici. Je classe par ordre d’importance.
Rien n’est dit sur la distinction entre fonction et procédure, distinction qui est pour moi très importante, surtout dans le cadre du cours de mathématiques.
Je ne rappelle pas ce qu’est une fonction en mathématiques. De plus, il n’y a pas vraiment d’idée de procédure (qui s’opposerait à l’idée de fonction) en mathématiques.
En informatique, une procédure est grossièrement :
Une famille de langages dits fonctionnels, très proche des mathématiques, fait une distinction entre les procédures dites pures, appelées justement fonctions, et les autres procédures (impures).
Je fais la distinction dans mon cours de BTS en ayant deux chapitres :
Même si la différence est subtile et difficile à faire passer en seconde, cela vaut vraiment le coup de l’évoquer.
Pour moi l’intérêt va au-delà de « faciliter la lecture d’un programme complexe » (et au passage, le mot « interpréter » est ambigu). Pour une première définition, j’aurais écrit, juste avant la première phrase :
Pour ne pas se répéter lorsque l’on veut faire faire plusieurs fois des actions similaires à la machine, ou afin de faciliter…
Rien n’est dit sur le return
, et les corrections de l’application 10
utilisent des procédés totalement différents pour la transmission de la
valeur de la somme :
return
en Python,Je ne suis pas pour mettre une espace entre le nom de la procédure et les parenthèses. Du plus, il aurait été intéressant de faire remarquer que même si une procédure ne prend pas de paramètre, la plupart des langages attendent des parenthèses vides lors de la définition et lors de l’appel de la procédure.
L’insertion de commentaires est bienvenue, mais :
Pages 9 et 10.
Ma remarque : Étant très fan de la Tortue (voir cette page), je suis dit à la première lecture de ce cahier qu’il ne pouvait pas être totalement mauvais. Il faut dire que cette première lecture était en diagonale.
Ce n’était donc pas une faute de frappe.
Mettons une majuscule.
Le dernier td 90
de l’exemple est inutile et troublant. On le peut pas
vraiment l’éviter de manière simple en utilisant rep 4
(au passage, il aurait
été intéressant de rappeler que c’est une boucle itérative), mais la Tortue
sera retournée dans sa position de départ.
L’appel de carre
n’a pas nécessité de parenthèses, alors que celui de alea
oui. Cette subtilité est peut-être à reprocher plutôt à GéoTortue dont je vais
contacter l’auteur.
Les trois figures étant en couleur, il aurait été intéressant d’en parler dans la consigne, voire de ne pas en parler du tout si c’est pour renvoyer vers la documentation.
!!!
L’indication de la figure 2 n’a pas le « motif ci-contre »
annoncé.
Les noms des procédures ont été choisis de façon troublante :
etoile
fig2
, aurait pu être mosaique
spi
, aurait pu être spirale
Je n’ai pas (encore) eu le courage d’examiner le code des corrections.
Je n’ai pas le temps de m’attaquer au reste de l’ouvrage, mais si vous me le demandez gentiment, je peux répondre à une question ou critiquer une activité entière.
Bonne lecture !