Contribution en algo lycée

Il faudrait (peut-être ?) préciser que les points A et B doivent être distincts.

Mes accolades, ne s'affichent pas .... :-( Merci beaucoup Braun.

C'est pourtant pratique, en général. Parce que deux points A et B peuvent vivre chacun leur vie et se retrouver confondus à un moment donné.

Merci de mettre en ligne ton travail , je vais m'en inspirer pour faire un travail avec mes 2nde ( le travail sur les droites)
Le sujet est interessant.

Par contre combien de temps cela te prends pour faire cela, car mes élèves de seconde ( dans un lycée tout à fait correct) auraient un peu de mal,enfin je verrais bien !

Petite critique : j'aime pas trop tes algo en langage naturel, ils ressemblent trop à un programme écrit avec algobox.
J'écrirai plutôt l'algo ainsi

entrée :x_a etc....
Sortie m et p
traitement :
plus proche d'un esprit "fonctionnel"


Je suis admiratif de ceux qui arrivent à faire de la programmation en python en 2nde, ptre l'année prochaine je tente !

J'écrirai plutôt l'algo ainsi
...
plus proche d'un esprit "fonctionnel"

Moi aussi. D'ailleurs, si on fait du Python, je serai plutôt favorable à introduire le plus rapidement possible les fonctions (avec la commande def). Surtout que les fonctions sont au programme de seconde.

Je propose l'exercice suivant :

savoir si deux segments du plan ont un point commun.

D.S

parisse a écrit:

J'ai du mal a comprendre pourquoi le concept de fonction argument et valeur de retour n'apparait pas dans l'algorithmique au lycée.

Merci, Parisse, permets que j'applaudisse des deux mains. Pendant des années j'ai milité en vain pour qu'on privilégie des langages "fonctionnels" au lycée. Je ne mentionnerai que les années sinistres où pour faire vendre les TO7 et MO5 on a saboté toutes les tentatives de généraliser l'initiation à des langages comme Lisp... Voire Prolog mais ça c'est une autre histoire.

(tu) pour ce dernier argument.

Bon, disons rapidement qu'un langage fonctionnel, c'est un langage où on peut avoir des variables de type fonction, et donc des fonctions qui prennent en argument des fonctions (des fonctionnelles donc). Par exemple on peut écrire une fonction dichotomie(f,a,b,epsilon) qui prend en argument la fonction f dont on cherche une racine. Dans un langage non fonctionnel, on appele dichotomie(a,b,epsilon) et la fonction f est écrite explicitement dans l'algorithme, on devra modifier le code source si on change de fonction f. Par exemple à ma connaissance toutes les calculatrices ont un langage non fonctionnel (sauf les HP en mode polonaise inversée et les TI nspire en lua). La plupart des langages sur PC sont fonctionnels (y compris le C).
Mais en fait, on entend souvent par fonctionnel un style de programmation, dans lequel on favorise les appels de fonction (récursifs ou récursifs croisés) à des itérations. Par exemple l'algorithme d'Euclide récursif
pgcd(a,b):=si b=0 alors return a; sinon return pgcd(b,irem(a,b)); fsi
Je ne suis pas du tout un expert de langage fonctionnel, d'autres sauront surement mieux en expliquer l'intérêt.
Pour l'orienté objet, on n'en n'a pas parlé. C'est une extension des types structurés dans lequel on agrège en un seul type non seulement des données mais aussi des méthodes qui les manipulent.

blitz écrivait:

---

> Il est écrit "deux points", ils sont forcément
> distincts, sinon ça fait un seul point, non ?



les trois mousquetaires étaient quatre, Dr Jekyll et Mister Hyde étaient le même bonhomme.

Plus sérieusement, "soit B ton voisin Bob et soit A, le mari d'Alice".
Tant qu'Alice ne s'est pas remariée avec Bob, ça fait deux bonshommes, par la suite un seul.

C'est sympa d'avoir des éclaircissements.
Je n'ai pas encore tout compris : pour moi un langage fonctionnel est un langage qui utilise des fonctions.... Est-ce que cela peut se simplifier à cela ?

Pour la programmation à l'aide de fonctions en secondes, j'y suis loin, très loin.
Si déjà une majorité des élèves arrive à écire un petit algorithme/programme ( une instruction condiionnelle, ou une boucle) je serais déjà très content...
Cet objectif me semble inaccessible pour moi avec le temps qui j'y passe pour mes élèves de lycée en maths. Et malgré cela, je suis à la peine pour finir les programmes..
De plus un grand nombre de collègues n'ont pas cette vision, et il faut dire qu'avec le peu d'heures qu'ils ont eu en formation, il ne peut pas en être autrement.
Je comprends donc que cela ne soit pas au programme du lycée.
Cela serait ptre différent une petit bout de programmation se fait au collège ( ptre bientôt ?)

Par contre en ISN c'est une base de tous les programmes, et malgré cela quelques d'élèves qui ont choisi la spé ont du mal à comprendre cet aspect.

Bonjour Nicolas.

D'après la définition de Parisse, pascal est un langage fonctionnel, turbo-pascal (au moins dans ses premières versions) est un langage non fonctionnel.

amicalement,

e.v.

Merci pour la peine prise à expliquer. Je crois que j'ai compris.

S

Bonjour,
Au collège, contrairement au lycée, je me limiterais à un langage strictement impératif et procédural. Pour moi l'idéal aurait été Forth ou les calculatrices RPN, à la rigueur Logo, qui permettent une aproche ludique du calcul.

@parisse :
> l'algorithmique devrait commencer par là : être capable d'écrire en ligne (gestion des priorités, parenthèses...

Entièrement d'accord. Ce qui pose le plus de problèmes dans le secondaire (et sans doute aussi après), c'est qu'une majorité de lycéens est inapte à contrôler un résultat parce qu'elle n'arrive pas à remettre en ligne une expression algébrique.

Dans ces conditions, on se demande ce qu'ils comprennent à l'algèbre et à l'analyse.

Demandez d'écrire en ligne une innocente fraction rationnelle dans un devoir, et constatez l'ampleur des dégâts : les priorités opératoires sont superbement ignorées.


@Braun : Logo, c'est le Bien ! -D

" l'algorithmique devrait commencer par là : être capable d'écrire en ligne (gestion des priorités, parenthèses... "

Pour ma part, je ne suis pas d'accord. Pour deux raisons :
1) La gestion des prioriétés, parenthèses & cie relève du programme de mathématiques, je ne vois pas l'intéret d'y ajouter une dimension "informatique".
2) j'ai personnellement appris la programmation sans aucune notion de maths, et il y a des milliards de choses à faire dans ce domaine sans maths (manipulations de chaines de caractères, programmation de petits jeux, ...). Et cela bloque beaucoup d'élèves. Par exemple, j'ai vu une élève ne pas être capable de d'écrire un programme énumérant les solutions entière entre 1 et 10 d'une équation alors qu'elle avait compris la notion de boucle : elle était complètement bloquée par la signification réelle de "résoudre une équation" (c'est à dire : "trouver les nombres qui rendent l'équation vraie"). Donc elle a dit que "l'algorithme c'est trop dur".

Dans cette optique, je n'aime pas trop la première activité de Yann avec les équations de droites : au final, ce n'est qu'une ré-écriture du cours en version informatique, l'intérêt du programme obtenu n'est pas flagrant (un élève connaissant bien son cours armé d'une calculatrice collège sera tout aussi efficace). Je ne dis pas qu'il ne faut absolument pas en faire (je fais faire le même type d'exos à mes élèves, je suis bien conscient que l'objectif ici est aussi de réviser le cours par un moyen détourné), mais si l'intérêt est de travailler sur la structure si/alors/sinon, on peut très bien aller chercher autre chose que des maths. Par exemple, je leur fait programmer un petit quizz sous forme de QCM, le programme final ressemblant à

score=0
print "Question 1 : quelle est la couleur du cheval blanc d'HIV ?"
print "1) Blanc"
print "2)Rouge"
rep = input('Votre réponse :')
if rep == 1 :
   print "Bravo !"
   score = score +1
else :
   print "Raté, il était blanc !"
print "Question 2 : qui est le prof le plus cool ?"
print "1) Le prof de maths"
print "2) Le prof de physique"
...

C'est pas dur, c'est ludique, on a un programme qui présente un intérêt (même si on ne va pas le vendre à 40 000 exemplaires, on peut y faire jouer des gens) et ça met en jeu tout ce dont on a besoin pour programmer.

Pour pousser encore plus loin mon idée : le site du zéro apprend à programmer jusqu'à un niveau ma foi tout à fait honnête et ne parle pas de mathématiques de tout le tutoriel si ce n'est des opérations arithmétiques élémentaires (et pour cause : on n'a pas besoin de plus !).

Par contre j'aime bien l'acti avec les probas : ici on fait un programme utile qui simule une situation qu'on aurait du mal à simuler à la main. Je vais surement l'utiliser avec mes élèves.

Pour résumer, ce que je préférerais comme approche de l'algo : une première phase de programmation où on apprend à programmer en dehors de tout objet mathématique dépassant l'abstraction de la division, puis des applications dans plusieurs branches des sciences : en maths (algo de dichotomie, newton, intégration numérique, simulations probabilistes...), en physique (simulation de trajectoires, de ciruits électriques, ...), en bio (évolution de populations et pleins d'autres trucs rigolos que je ne connais pas bien).
Parce que honnêtement, voir les lycéens se traîner de "l'algorithmique" pendant 3 ans et ne pas avoir un algo plus évolué que "calculer la somme des u_k pour n allant de 1 à n" (cf bac 2012), je me dis qu'au final les lycéens n'ont pas appris grand chose : ce programme est complètement trivial pour n'importe qui ayant compris comment manipuler une boucle "pour" (base de la base en programmation) et a une compréhension rudimentaire de ce qu'est une suite.

sebsheep:
C'est une vraie question en effet: l'algorithmique doit-elle etre introduite sur des notions de maths ou pas? Vu que l'enseignement fait partie du cours de maths, j'aurais tendance a dire oui (et il me semble que c'est ce qui ressort des commentaires du programme de maths) mais on pourrait avoir un cours d'informatique qui ne soit pas enseigne a l'interieur des maths et les exemples foisonnent dans d'autres disciplines (par exemple l'ADN et l'ARN permettent de faire des choses tres interessantes en algorithmique).
Par contre, je maintiens que l'algorithmique necessite de comprendre les notions de priorite, parenthesage, ... bref de savoir ecrire une ligne de commande, sauf a rester completement bloque dans un environement, ce que evidemment certains editeurs souhaitent (ca n'empeche evidemment pas de commencer avec un langage a la syntaxe simplifiee, par exemple de type logo, et ce n'est pas par hasard que j'ai implemente un module dessin tortue dans Xcas). Sinon, on est bien oblige a un moment donne d'ecrire une ligne d'un programme, or une ligne de programme c'est une ligne de commande. Si on n'est pas capable d'ecrire une ligne de commande, on ne peut pas ecrire un programme!

Vu que l'enseignement fait partie du cours de maths, j'aurais tendance a dire oui (et il me semble que c'est ce qui ressort des commentaires du programme de maths)

Ce que fait et préconise l'EN n'est pas forcément ce qu'il faudrait faire... En tout cas l'argument "c'est dans les programmes donc c'est bien de faire comme ça" ne me convainc pas du tout.

Par contre, je maintiens que l'algorithmique necessite de comprendre les notions de priorite, parenthesage,

Je suis d'accord et n'ai jamais dit le contraire. La maîtrise des "opérations artihmétiques élémentaires" inclus ces notions ; je ne parle pas de simplification/développements/factorisation ou autre, juste les notions de priorité d'opérations. Et ça normalement un cinquième "bien formé" sait manipuler cela sans problème ; donc les élèves arrivant en seconde devraient (si tout se passait pour le mieux dans le meilleur des mondes et que les élèves maîtrisaient tous les 3/4 des programmes de l'année n-1) être parfaitement à l'aise avec cela.
Le problème est bien antérieur à l'introduction de l'algorithmique.

Pourtant on peut créer des programmes avec Scratch sans savoir lire de ligne de commande.

Oui et non car on peut être rapidement amenés à calculer des choses du type (x+y)/2. Et là la maîtrise des priorités opératoires est essentielle.

-> sebsheep: bon, disons alors que savoir écrire une ligne de commande est un préalable à écrire des algorithmes. Mais je crains que ça ne soit pas bien maitrisé à l'entrée en seconde (si j'en juge par certaines erreurs d'étudiants), et donc à revoir, et je pense que ça pourrait aussi être bénéfique pour aider à résoudre certaines difficultés en maths, justement en en reparlant au début de l'algorithmique, je pense en particulier à la multiplication implicite et aux confusions entre produit, variable ayant 2 lettres, et pour les parenthèses produit ou fonction appliquée à un argument (par ex. x(x+1) ou f(x+1)).
Ensuite sur l'enseignement de l'algorithmique avec ou sans les maths, je ne suis pas contre le principe d'un enseignement hors des maths, mais il faut aussi en tirer les conséquences, un horaire à part, donc forcément pris sur les disciplines existantes, et on perdrait à mon avis la possibilité d'aide à la compréhension mathématique que peuvent apporter certains algorithmes.
-> nicolas.patrois: je ne connais pas scratch, je suppose qu'on n'y tape pas de ligne de programmes puisque vous le prenez en exemple, est-il possible de faire des algos intéressants d'un point de vue scientifique, disons par exemple dans un domaine non mathématique un algorithme d'alignement d'ADN (puisque j'évoquais le sujet) ?

Ben, si on raisonne en disant que ca devrait etre maitrise avant, donc on ne le refait pas, on ne fait qu'aggraver le probleme, les notions enseignees n'etant pas assises sur des bases solides. Alors bien sur le lycee ou la fac ne peut pas faire tout ce qui n'a pas ete fait en amont, mais justement l'algorithmique est un sujet neuf au lycee, ca pourrait etre l'occasion de s'assurer que les bases sont bien comprises.
Ensuite sur le type de langage, peut-etre que nous avons une divergence importante sur le but de l'algorithmique: pour moi, cet enseignement dans la filiere scientifique doit servir aux sciences, donc se nourrir des themes qui y sont abordes (et c'est bien dans cet esprit que les programmes sont rediges en maths actuellement) mais egalement donner un autre eclairage a ces themes (j'evoquais la question de la multiplication implicite, mais les exemples sont legions en maths, du crible d'Erathosthene, de l'algorithme d'Euclide -y compris Bezout- en arithmetique, des suites recurrentes, la dichotomie, l'integration par des methodes de quadrature, des proba/stats ou des simulations permettent d'eclairer certains phenomenes, ...). En fait il y a beacoup d'exercices qu'on fait faire en maths qui sont essentiellement des algorithmes executes a la main, et qu'on fait faire parce qu'ils rendent concrets des notions et aident ainsi a la comprehension de theories (ca commence d'ailleurs tres tot avec les operations au primaire). Je ne vois donc pas l'algorithmique comme une difficulte en plus, mais comme une chance en plus de comprendre. Pour la seconde, ca pourrait evidemment etre plus ouvert, mais il me semble que l'esprit du programme actuel est bien d'interagir entre algorithmique et maths (ce qui n'exclut bien evidemment pas de traiter d'autres thematiques).
Sur scratch, je n'ai pas trop le temps de regarder, c'est clair que j'ai un a priori defavorable sur ce qu'on peut faire en programmation "graphique" pour des algorithmes comme ceux que j'ai pris en exemple, maintenant peut-etre que je me trompe, mais je voyais plus ca comme une initiation a faire au primaire debut de college (comme logo).