Partagez
Voir le sujet précédentAller en basVoir le sujet suivant
ben2510
Érudit

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par ben2510 le Mar 26 Sep - 20:49
Tu as bien sûr raison, ta forme est généralisable à toutes les sommes de termes f(k).
Cela rejoint les premières remarques sur le fait que 1+2+3+...+n est trop simple à calculer pour nécessiter un algorithme, d'ailleurs.
Call_BB5A
Niveau 5

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Call_BB5A le Mar 26 Sep - 22:25
@e1654d a écrit: On a vraiment besoin de travailler en sup contre l'habitude de input/print.

J'entends bien la remarque, mais peut-on s'en passer réellement ; j'explique :

* Hormis les élèves qui suivent l'option ISN (et pas tous) presque aucun n'ont appris Python au lycée, puisque c'est hors programme officiel. Il ne devrait donc pas être si difficile que ça de leur donner de bonnes habitudes en cette matière, en leur répétant qu'on leur interdit d'utiliser input() et print() dans le corps d'une fonction. D'ailleurs comment se fait-il qu'ils utilisent print() et input() ? N'en parlez pas, et ils ne les utiliseront pas... (Sauf si vous en faites le même usage qu'en lycée en 2nde). Au delà du problème de input() et print(), l'exemple de code de la fonction discriminant() de L1 (au bas de la page 2 du pdf donné plus haut) montre surtout que ces étudiants non pas compris la notion de paramètre. C'est cela qu'il convient d'expliquer davantage ; et les problèmes de print() et input() disparaîtront d'eux mêmes en grande partie.

* L'aménagement du programme de seconde ne s'arrête pas à l'écriture d'algorithmes. La programmation y est explicitement indiquée, ainsi que la notion de type de données. Ce dernier point renforce l'intérêt d'utiliser la fonction input() : comprendre que la valeur retournée est une chaîne de caractères et qu'elle ne peut être utilisée directement dans un calcul, une conversion en un entier ou un flottant s'impose.

* Enfin, puisqu'on nous demande en seconde d'enseigner la programmation, on se doit d'écrire des programmes. Un programme dans lequel il n'y a ni entrée ni sortie n'est d'aucune utilité. Les élèves ont besoin d'avoir des réponses concrètes, de comprendre qu'on alimente le programme en entrée, avec des données qu'ils peuvent saisir, et que l'on obtient en sortie un résultat qu'il peuvent voir. On ne va tout de même pas mettre en dur les données dans le programme et devoir modifier son code à chaque fois qu'on veut changer les données en entrée de l'algorithme. Ce serait, non pas un retour au minitel, mais à celui des cartes perforées.

Vous l'aurez compris, je suis partisan des print() et input() .

Code:

# Programme de calcul de l'indice de masse corporelle

# définition de la fonction IMC ayant pour paramètres la masse et la taille
def IMC(masse, taille):
    return masse / taille**2

# lecture de la taille t et de la masse m
t = float( input("Quelle est votre taille (en m) ? ") )
m = float( input("Combien pesez-vous (en kg) ? ") )

# calcul et affichage de l'IMC
print("Votre IMC est de", IMC(m,t))
avatar
Balthazaard
Esprit éclairé

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Balthazaard le Mar 26 Sep - 23:13
@Call_BB5A a écrit:
@e1654d a écrit: On a vraiment besoin de travailler en sup contre l'habitude de input/print.

J'entends bien la remarque, mais peut-on s'en passer réellement ; j'explique :

* Hormis les élèves qui suivent l'option ISN (et pas tous) presque aucun n'ont appris Python au lycée, puisque c'est hors programme officiel. Il ne devrait donc pas être si difficile que ça de leur donner de bonnes habitudes en cette matière, en leur répétant qu'on leur interdit d'utiliser input() et print() dans le corps d'une fonction. D'ailleurs comment se fait-il qu'ils utilisent print() et input() ? N'en parlez pas, et ils ne les utiliseront pas... (Sauf si vous en faites le même usage qu'en lycée en 2nde). Au delà du problème de input() et print(), l'exemple de code de la fonction discriminant() de L1 (au bas de la page 2 du pdf donné plus haut) montre surtout que ces étudiants non pas compris la notion de paramètre. C'est cela qu'il convient d'expliquer davantage ; et les problèmes de print() et input() disparaîtront d'eux mêmes en grande partie.

* L'aménagement du programme de seconde ne s'arrête pas à l'écriture d'algorithmes. La programmation y est explicitement indiquée, ainsi que la notion de type de données. Ce dernier point renforce l'intérêt d'utiliser la fonction input() : comprendre que la valeur retournée est une chaîne de caractères et qu'elle ne peut être utilisée directement dans un calcul, une conversion en un entier ou un flottant s'impose.

* Enfin, puisqu'on nous demande en seconde d'enseigner la programmation, on se doit d'écrire des programmes. Un programme dans lequel il n'y a ni entrée ni sortie n'est d'aucune utilité. Les élèves ont besoin d'avoir des réponses concrètes, de comprendre qu'on alimente le programme en entrée, avec des données qu'ils peuvent saisir, et que l'on obtient en sortie un résultat qu'il peuvent voir. On ne va tout de même pas mettre en dur les données dans le programme et devoir modifier son code à chaque fois qu'on veut changer les données en entrée de l'algorithme. Ce serait, non pas un retour au minitel, mais à celui des cartes perforées.

Vous l'aurez compris, je suis partisan des print() et input() .

Code:

# Programme de calcul de l'indice de masse corporelle

# définition de la fonction IMC ayant pour paramètres la masse et la taille
def IMC(masse, taille):
    return masse / taille**2

# lecture de la taille t et de la masse m
t = float( input("Quelle est votre taille (en m) ? ") )
m = float( input("Combien pesez-vous (en kg) ? ") )

# calcul et affichage de l'IMC
print("Votre IMC est de", IMC(m,t))

Dans un des documents il me semble qu'il n'y a plus de déclaration de variables, la notion de type devient transparente (ça va poser des problèmes si on passe à autre chose style java)

Je comprend parfaitement les arguments anti print() et input(), mais je suis assez d'accord avec toi. Que les print() et input() ne se baladent pas à l’intérieur du programme on peut parfaitement le comprendre mais aller dire que placer un input() en tête et terminer par un print() c'est le MAL et que cela va créer une crise existentielle parmi des étudiants de prépa quand on leur présentera la notion de  paramètre (et les formes de passage...qui sont d'un autre niveau de complexité), je trouve cela un peu gros et cela me semble quelque part relever d'une certaine forme d'intégrisme mal adaptée au public (seconde) que l'on vise.
Quelle sera la réaction des dits étudiants quand on leur dira qu'une fonction continue ce n'est pas "en ne levant pas la main" mais avec des epsilon et des alpha...?
j'ai l'impression que tous les gens de fac qui parlent disent des choses très vraies mais se trompent totalement sur les capacités du public que l'on a.
On rigole de moi sur la somme des entiers...j'affirme.

1) Que quasiment aucun élève de seconde (avec ou sans print()) n'est capable de la programmer par lui même
2) Qu'il est impossible de trouver un programme non trivial réalisable par un nombre significatif (ie>2) d'élèves en seconde

J'emploie à dessin le mot programme pour éviter toute polémique sur fonction/méthode/procédure/algorithme/etc
avatar
Guermantes729
Habitué du forum

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Guermantes729 le Mer 27 Sep - 7:09
Pour parler encore de ma petite expérience, mon fils est en MPSI (au lycée du Parc dont je pense on ne peut remettre en question la hauteur des exigences, en info) , il n'avait jamais fait d'info, ni d'algo autre que des hyper basiques, et l'info en CPGE ne lui pose aucun problème pour autant (tu vas me dire, pour l'instant^^)

Je pense que là aussi, il vaut mieux ne rien apprendre aux élèves que leur apprendre des sottises si on n'est pas compétent.

Je suis comme Furby, je me débrouille pas trop mal seule sur ma feuille ou mon ordi , mais suis bien incapable de l'enseigner correctement car n'ai en aucun cas la distance, le recul, la maitrise nécessaires....et je préfère ne rien faire que faire du "mal" :/
avatar
Furby
Niveau 7

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Furby le Mer 27 Sep - 7:35
Merci Guermantes, je me sens moins seul !
Par contre j'ai des secondes depuis plusieurs années, j'ai décidé de continuer majoritairement sur algobox (comme les collègues qui ont décidé de ne pas tenir compte des nouvelles recommandations dans la mesure où notre cher IPR ne nous en a même pas informés), et j'introduirai petit à petit les rudiments de python que je vais quasiment découvrir avec eux, en leur disant honnêtement ce qu'il en est de ma part.
avatar
Guermantes729
Habitué du forum

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Guermantes729 le Mer 27 Sep - 7:49
@Furby a écrit:Merci Guermantes, je me sens moins seul !
Par contre j'ai des secondes depuis plusieurs années, j'ai décidé de continuer majoritairement sur algobox (comme les collègues qui ont décidé de ne pas tenir compte des nouvelles recommandations dans la mesure où notre cher IPR ne nous en a même pas informés), et j'introduirai petit à petit les rudiments de python que je vais quasiment découvrir avec eux, en leur disant honnêtement ce qu'il en est de ma part.



Pour la petite histoire, lors de ma dernière inspection (en Février 2013), en TS, j'utilisais algobox et en entretien avec l'IPR j'étais un peu gênée pour le lui dire pensant ramasser une volée de bois vert et elle m'avait dit "au contraire!! je suis bien d'accord avec vous!! je ne sais pas pourquoi on dit tant de mal d'Algobox, c'est une bonne façon d'introduire l'algorithme sans s'embarrasser d'un langage!"

comme quoi...même les IPR sont parfois déboussolés avec toutes les informations contradictoires qu'ils reçoivent je pense :/
e1654d
Niveau 6

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par e1654d le Mer 27 Sep - 10:02
Je veux absolument clarifier que je ne me moquais pas de vous, Balthazaard, à propos de la somme des entiers ; au contraire, cet exemple m'a fait sourire en communion avec vous car je le traite aussi et la question d'utiliser la formule close se pose (ce qui permet de rappeler que les math permettent aussi d'écrire des programmes plus efficaces !), ce qui me conduit à dire exactement la même chose : on prend un exemple simple parce que l'objet réel est bien sûr d'apprendre à écrire une boucle. Je vous présente mes excuses si je vous ai blessé.

Quand je parle de input/print, ce n'est pas au sens littéral de ces fonctions en Python mais de la façon corsetée de concevoir un programme comme une entrée texte / un traitement / un affichage. Bien sûr qu'un programme doit avoir une entrée et une sortie, mais tout le propos (et ce depuis les années 1970 en fait) est de dire que la notion de fonction, avec des paramètres et une valeur de retour, peut correspondre mieux à cette idée générale d'entrée / sortie tout en étant plus souple et pratique que de passer systématiquement par des flux d'octets.

Dans les premières années après la réforme de 2013, je faisais en effet mon cours sans parler du tout de ce qui se fait en lycée, et j'avais un certain nombre d'étudiants (les moins doués ; il doit y en avoir moins au Parc que chez moi !) persistait longtemps à parler de "fonction qui affiche telle chose" au lieu de renvoie, ce qui n'était pas qu'une erreur de plume mais révélait une confusion réelle. C'est pourquoi désormais je "critique" explicitement en début d'année, non pas bien sûr les collègues du secondaire, mais la façon qui était jusqu'à aujourd'hui préconisée par les programmes officiels et les sujets du bac.

Mais bien sûr il n'y a pas que la prépa, si j'en parle c'est parce que c'est ce que je connais. Au delà des prépa, c'est un fait admis par les informaticiens en général qu'il est mieux d'apprendre à programmer avec des fonctions : les entrées sorties par flux de caractères sont un domaine de spécialité (qui relève des interfaces utilisateurs et suppose, pour être bien fait, des compétences en analyse lexicale qui ne sont pas simples et donc pas judicieuses à exposer à des débutants) ; on en écrit parfois, mais le problème c'est de le faire dès le début, de le faire systématiquement et d'en faire l'alpha et l'oméga de la programmation. C'est je crois le sens du changement de programme en seconde (en tout cas c'est ainsi que le comprennent tous les informaticiens avec qui j'en ai parlé).

Pour prendre l'exemple de l'IMC, je pense que c'est aussi bien, après avoir écrit la fonction qui est proposée, d'utiliser la console Python (qu'on a dans Pyzo par exemple), d'appeler IMC(65, 155) et d'obtenir le résultat dans la console, en bénéficiant du fait que c'est alors la console qui s'occupe de l'affichage et pas nous (on se concentre sur l'essentiel). 9a permet de ne pas se fatiguer à écrire du blabla à chaque fois et de plus on peut élaborer en écrivant par exemple
Code:

def en_surpoids(masse, taille) :
   return IMC(masse, taille) > 25  # si je me rappelle bien la valeur

ce qui est impossible avec du input/print à moins de se fader des redirections d'entrées sorties Unix, et là je suis d'accord que c'est hors de portée d'un seconde normal et surtout hors de propos dans un cours de math.

De toutes façons, de nos jours, quand vous appelez un programme, vous le faites rarement en ligne de commande, donc je ne vois pas en quoi ça serait perturbant de ne pas avoir d'invite textuelle à saisir une masse et une taille. D'ailleurs si vous allez sur une page web de calcul d'IMC (il y en a plein), il va y avoir du code pour gérer l'interface avec la page HTML (ce qui ne nous intéresse pas directement en math en 2nde) et, si c'est bien fait, la même fonction IMC (même si dans un autre langage).

Plus généralement, c'est fréquent pour un scientifique d'écrire un programme par exemple pour étudier numériquement une limite ou que sais-je ; il le fait dans un environnement de programmation adapté (Scilab ou python avec numpy/scipy par exemple) et exploite les capacités d'affichage de l'environnement pour se concentrer sur l'essentiel, qui consiste la plupart du temps à appeler des fonctions et à en écrire. Même pour les non scientifiques, il y a des tâches répétitives qu'on fait (sous un traitement de texte ou autre) qui peuvent parfois être automatisées au moyen d'un langage de script (plus ou moins bon, d'ailleurs) qui a vocation à s'exécuter dans la machine virtuelle qu'est le logiciel que vous scriptez, et pas directement Unix. Même si ça arrive aussi (encore que certains logiciels proposent des liaisons directes avec Python ce qui permet de les manipuler depuis une API fonctionnelle).

Cela dit c'est vrai que la notion de fonction n'est pas triviale ; ça a déjà été remarqué.

Enfin, ces discussions intéressantes montrent une fois de plus que la "concertation" préalable à cette réforme aurait sans doute être plus large et impliquer davantage des enseignants sur le terrain, je pense qu'on sera tous d'accord là dessus.
avatar
Balthazaard
Esprit éclairé

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Balthazaard le Mer 27 Sep - 10:24
Je n'avais pas pris cela mal, mais je pensais surtout aux remarque des autres messages. Il est évident que dans un but opératoire, écrire un programme pour calculer la somme des entiers de rime à rien, par contre si on veut se concentrer sur l'écriture d'une boucle avec condition d’arrêt, avec en plus les problèmes relatifs à l'affectation du type S=S+n je ne vois pas ce qu'on peut faire de plus simple. Deux choses qui si j'en crois ma maigre expérience de l'enseignement de l'info en seconde sont très, mais très loin d'être évidentes pour les élèves. (Comme d'ailleurs le sens mathématique de "la somme des n premiers entiers"....).

Je comprends bien le sens de votre message. je raisonne peut-être en prof de maths désabusé, ce que nous enseignons en seconde est tellement (pour moi ) éloigné des vraies maths, qui sont de plus en plus renvoyées à l'année n+1 que l'argument qui consiste à dire "faisons tout de suite des choses correctes, quitte à ne pas toujours pouvoir les justifier de manière accessible" n'a plus grande portée pour moi.

Après il y a aussi une question de but et de compréhension du but de tout cela, je pensais (naïvement) que l'introduction d'une part d'algorithmique permettrait d'inculquer un peu de rigueur dans le raisonnement, un côté "pratique" , donc plus, j'ose à peine l'écrire, "ludique" par la manipulation et surtout montrer de manière visuelle l'importance des règle de syntaxe (avec en miroir les écritures mathématiques de plus en plus malmenées par les élèves)
J'avais tort sur toute la ligne, l'info emm....prodigieusement les élèves et ce qui est pire, les bons comme les mauvais...ils ne comprennent absolument pas les tenants ni les aboutissants et encore pire que devant un problème de math, renoncent dès le premier blocage.
j'avais surtout tort en me trompant sur les buts, j'espérais que l'enseignement de l'info était là pour le bénéfice intellectuel qu'on pouvait en tirer et non pour former plus tard de vrais "informaticiens" (quel que soit le sens de ce terme)
Je l'assume.


Dernière édition par Balthazaard le Mer 27 Sep - 11:16, édité 3 fois
avatar
Balthazaard
Esprit éclairé

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Balthazaard le Mer 27 Sep - 10:31
Il y a quand même une chose qui me gène énormément...dans un des exemples cité comme "bon", l'auteur est quand même obligé de balancer une exception... (ce que la "mauvaise version" sans la défendre pour autant traitait en interne)
Il me semble difficile d'éviter ce recours si on veut uniquement du fonctionnel, je me vois mal débattre de ça en seconde. Ce n'est pas facile pour nos élèves. Leur compliquer les choses en seconde pour un bénéfice hypothétique (sur les plus mauvais) en bac +n me semble une option pour le moins risquée.

def algoMystere(M, N, P, Q) :
   """Paramètres : M, N, P, Q entiers relatifs non nuls
   Précondition : pgcd(M, N) = pgcd(P, Q) = 1"""
   if N % Q == 0 :
       X = 0
       while (M*X*Q+P*N) % (Q*N) != 0 and (-M*X*Q+P*N) % (Q*N) != 0 :
           X = X + 1
       if (M*X*Q+P*N) % (Q*N) == 0 :
           return (X, (M*X*Q+P*N) // (Q*N))
       else :
           return (-X, -(M*X*Q+P*N) // (Q*N))
   else :
       raise ValueError("Pas de solution")
avatar
Anaxagore
Guide spirituel

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Anaxagore le Mer 27 Sep - 10:45
Mieux vaudrait stocker les valeurs qui sont recalculées plusieurs fois dans la boucle.

_________________
"De même que notre esprit devient plus fort grâce à la communication avec les esprits vigoureux et raisonnables, de même on ne peut pas dire combien il s'abâtardit par le commerce continuel et la fréquentation que nous avons des esprits bas et maladifs." Montaigne

"Woland fit un signe de la main, et Jérusalem s'éteignit."
avatar
Prezbo
Niveau 10

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Prezbo le Mer 27 Sep - 11:38
@Balthazaard a écrit:Il y a quand même une chose qui me gène énormément...dans un des exemples cité comme "bon", l'auteur est quand même obligé de balancer une exception... (ce que la "mauvaise version" sans la défendre pour autant traitait en interne)
Il me semble difficile d'éviter ce recours si on veut uniquement du fonctionnel, je me vois mal débattre de ça en seconde. Ce n'est pas facile pour nos élèves. Leur compliquer les choses en seconde pour un bénéfice hypothétique (sur les plus mauvais) en bac +n me semble une option pour le moins risquée.

def algoMystere(M, N, P, Q) :
   """Paramètres : M, N, P, Q entiers relatifs non nuls
   Précondition : pgcd(M, N) = pgcd(P, Q) = 1"""
   if N % Q == 0 :
       X = 0
       while (M*X*Q+P*N) % (Q*N) != 0 and (-M*X*Q+P*N) % (Q*N) != 0 :
           X = X + 1
       if (M*X*Q+P*N) % (Q*N) == 0 :
           return (X, (M*X*Q+P*N) // (Q*N))
       else :
           return (-X, -(M*X*Q+P*N) // (Q*N))
   else :
       raise ValueError("Pas de solution")

Je dis peut-être une bétise (et si c'est le cas je m'en excuse) mais il me semble qu'on aurait déjà le même problème avec une fonction retournant les solutions d'une équation du second degré.
avatar
VinZT
Expert

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par VinZT le Mer 27 Sep - 11:42
On peut toujours muscler les préconditions.

_________________

« Il ne faut pas croire tout ce qu'on voit sur Internet » Victor Hugo.
« Le con ne perd jamais son temps. Il perd celui des autres. » Frédéric Dard
« Ne jamais faire le jour même ce que tu peux faire faire le lendemain par quelqu'un d'autre » Pierre Dac
« Je n'ai jamais lâché prise !» Claude François
« Un économiste est un expert qui saura demain pourquoi ce qu'il avait prédit hier ne s'est pas produit aujourd'hui. » Laurence J. Peter
avatar
Prezbo
Niveau 10

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Prezbo le Mer 27 Sep - 11:44
@VinZT a écrit:On peut toujours muscler les préconditions.

Oui, mais le nombre de solutions dépendant des paramètres, sous quelle forme retournes-tu les solutions ?

(Je ne dis pas que c'est infaisable, mais ça me semble poser des problèmes qui risquent d'être au-delà des préoccupations d'un lycéen.)
avatar
Balthazaard
Esprit éclairé

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Balthazaard le Mer 27 Sep - 12:35
Dans cet exemple ce serait du bodybuilding
Et d'ailleurs comment la programmer?....on rentrera la formule du second degré en console,OK, on obtiendra en sortie, un nombre ou une liste de deux nombres sans aucune indication?
Et si on l'intègre dans un autre programme, quel sera le type de variable à affecter au retour de la fonction? je suppose qu'en Python on peut s'en sortir mais dans un langage plus fortement déclaratif?
Moi aussi je me pose des questions
archeboc
Sage

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par archeboc le Mer 27 Sep - 13:43

@Balthazaard a écrit:
J'avais tort sur toute la ligne, l'info emm....prodigieusement les élèves et ce qui est pire, les bons comme les mauvais...ils ne comprennent absolument pas les tenants ni les aboutissants et encore pire que devant un problème de math, renoncent dès le premier blocage.
j'avais surtout tort en me trompant sur les buts, j'espérais que l'enseignement de l'info était là pour le bénéfice intellectuel qu'on pouvait en tirer et non pour former plus tard de vrais "informaticiens" (quel que soit le sens de ce terme)
Je l'assume.

Vous avez sur la situation le coup d'oeil d'un vieux briscard qui a vu naître l'informatique grand public. Essayons d'imaginer que nous sommes avec cet outil comme l'étaient nos parents avec l'électronique : ils avaient vu naître le transistor, manipuler un fer à souder était pour eux naturel. Ils ont eu du mal à comprendre que cela ne nous intéressait qu'assez peu. Ils regardaient, comme Boris Vian, les composants à l'arrière de la télévision avec des yeux émerveillés. Nous, c'était l'écran qui nous captivait.
De même aujourd'hui nous surinvestissons l'efficacité de la programmation informatique, parce que nous l'avons vu naître et que nous mesurons sa puissance. Nos enfants sont de l'autre côté, ils se contentent d'en profiter, comme on tourne un robinet.

Et que plus que devant un problème de math, ils renoncent au premier blocage, ce n'est pas étonnant non plus : l'interpréteur ou le compilateur sanctionne le moindre manquement à la règle, il n'y a ni aménagement, ni négociation possible. En dehors de ceux qui grandissent dans des milieux particulièrement intégristes, ils n'ont pas l'habitude d'une telle rigueur.

Call_BB5A
Niveau 5

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Call_BB5A le Mer 27 Sep - 14:10
@Balthazaard a écrit:Il y a quand même une chose qui me gène énormément...dans un des exemples cité comme "bon", l'auteur est quand même obligé de balancer une exception...

def algoMystere(M, N, P, Q) :
   """Paramètres : M, N, P, Q entiers relatifs non nuls
   Précondition : pgcd(M, N) = pgcd(P, Q) = 1"""
   if N % Q == 0 :
       X = 0
       while (M*X*Q+P*N) % (Q*N) != 0 and (-M*X*Q+P*N) % (Q*N) != 0 :
           X = X + 1
       if (M*X*Q+P*N) % (Q*N) == 0 :
           return (X, (M*X*Q+P*N) // (Q*N))
       else :
           return (-X, -(M*X*Q+P*N) // (Q*N))
   else :
       raise ValueError("Pas de solution")

Le fait que la fonction puisse échouer à retourner un résultat, montre nettement la distinction à faire entre l'algorithme et son implémentation. De ce point de vue, je trouve même que ceci pourrait être mieux programmé. Pourquoi déclencher l'exception tout à la fin dans un else ?

Il serait beaucoup plus clair de tester la condition contraire : le déclenchement de l'exception serait immédiat dans la logique du programme, et le contenu du if pourrait en être sorti, réduisant par la même le niveau d'imbrication.

Qui plus est le programme proposé répète une partie du code (entre le while et le if) qu'on peut éviter. Je me demande même s'il n'y a pas une erreur entre la seconde partie du test du while et le return dans le else. On a (-M*X*Q+P*N) % (Q*N) comparé à 0 et on retourne -(M*X*Q+P*N) // (Q*N). Le signe - ne devrait-il pas être dans la parenthèse lui aussi ? J'aurai écrit le programme plutôt sous la forme suivante, plus logique à mon sens, puisqu'on sort de la fonction dès que l'on trouve un reste nul :

Code:
def algoMystere(M, N, P, Q) :
   """Paramètres : M, N, P, Q entiers relatifs non nuls
      Précondition : pgcd(M, N) = pgcd(P, Q) = 1"""
   if N % Q != 0 :
       raise ValueError("Pas de solution")
   X = 0
   while True:
       if (M*X*Q+P*N) % (Q*N) == 0 :
           return (X, (M*X*Q+P*N) // (Q*N))
       if (-M*X*Q+P*N) % (Q*N) == 0 :
           return (-X, (-M*X*Q+P*N) // (Q*N))
       X += 1
e1654d
Niveau 6

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par e1654d le Dim 1 Oct - 10:34
@Balthazaard a écrit:Après il y a aussi une question de but et de compréhension du but de tout cela, je pensais (naïvement) que l'introduction d'une part d'algorithmique permettrait d'inculquer un peu de rigueur dans le raisonnement, un côté "pratique" , donc plus, j'ose à peine l'écrire, "ludique" par la manipulation et surtout montrer de manière visuelle l'importance des règle de syntaxe (avec en miroir les écritures mathématiques de plus en plus malmenées par les élèves)
J'avais tort sur toute la ligne, l'info emm....prodigieusement les élèves et ce qui est pire, les bons comme les mauvais...ils ne comprennent absolument pas les tenants ni les aboutissants et encore pire que devant un problème de math, renoncent dès le premier blocage.
j'avais surtout tort en me trompant sur les buts, j'espérais que l'enseignement de l'info était là pour le bénéfice intellectuel qu'on pouvait en tirer et non pour former plus tard de vrais "informaticiens" (quel que soit le sens de ce terme)
Je l'assume.

Je crois que nous sommes entièrement d'accord sur l'essentiel. Surtout sur la nécessité de la rigueur formelle et l'intérêt d'avoir un compilo qui ne rigole pas en face de soi. Raison pour laquelle je suis assez sceptique quant à Scratch, même si en y réfléchissant un peu plus je me dis que le système des blocs permet d'imprégner peu à peu les élèves de l'idée qu'un programme a une structure qui ne peut pas être n'importe quoi (ce qui, vu d'où je suis, semble être une difficulté plus importante qu'avant dans la rédaction des preuves chez les élèves).

Mais bien sûr cela est une forme de « naïveté » que nous partageons et qui se base sur l'idée qu'on aurait vraiment les conditions de temps, de moyens et d'attention pour enseigner effectivement cela. On sait bien que « ça n'est pas vraiment vrai dans la réalité » comme disait mon professeur de SI. Cependant, ça me parait être un problème général et orthogonal à la question de l'info et des math : tant qu'on n'aura pas, en tant que société, compris à nouveau que l'école est là, pour dire les choses vites, afin de transmettre aux élèves ce sont ils ont besoin et non ce dont ils ont envie, et que faire cela nécessite des moyens matériels mais aussi moraux (statut de l'école et des professeurs dans la société), on n'avancera pas, dans aucune discipline.

C'est pour ça que je continue de penser que le débat spécifique sur la façon d'enseigner l'informatique a un intérêt, indépendamment de cette question générale. Ce d'autant plus que je crains fortement que l'informatique serve sinon de nouveau terrain de jeu à ceux qui veulent déconstruire l'enseignement disciplinaire : un peu de bivalence (sans revalo, bien sûr) et progressivement tout le monde prof de tout. Et ça c'est non.

Sur les exceptions, j'ai relu l'article cité. Il semble que l'auteur donne cette version pour le cas où on voudrait absolument coller à ce qui se faisait dans le bac 2016, mais qu'il ne recommande pas d'aller jusque là. De toutes façons les exceptions ne sont même pas au programme en option informatique en MP, donc… Idem pour les remarques sur la répétition du code et des calculs : l'idée est manifestement de décalquer, à titre d'illustration, ce qui est fait en 2016 mais dans le cadre des fonctions, et non de réécrire entièrement l'algorithme d'une meilleure façon sur tous les aspects.
avatar
Balthazaard
Esprit éclairé

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Balthazaard le Dim 1 Oct - 14:12
D'accord avec toi.
Par contre pour l'exemple je ne vois sincèrement pas où on veut en venir, sinon à une impasse...il y a un cas où il n'y a pas de solution possible, comme on s'interdit d'afficher un message quelconque le "print()" (qu'au passage dans mes messages j'utilisais comme sortie générique quelle que soit sa forme effective), on lève une exception (qui par pirouette affiche un message!...pas l'exception, ni le programme, puisque les exceptions son gérées par le système....mais bien un message quand même!) et on laisse donc au système le soin de traiter, non pas un dysfonctionnement, mais un cas tout à fait prévisible par la théorie qui sert de base à l'algorithme.
Je suis perplexe
e1654d
Niveau 6

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par e1654d le Dim 1 Oct - 14:19
L'intérêt de l'exception, c'est qu'elle interrompra l'exécution du programme appelant, ce que ne fait pas un print. Si cette exception n'est pas rattrapée avant, elle le sera en effet au toplevel et provoquera l'affichage d'un message explicatif, mais c'est anecdotique.

Le problème est celui de la programmation défensive : la bonne façon de le faire, c'est avec des exceptions (ou des assert, ce qui y revient), mais c'est une notion avancée. En CPGE, on ne fait pas de programmation défensive (pour cette raison, mais pas seulement ; l'esprit est bien plus sur la rédaction de spécifications avec préconditions), donc je n'imagine pas qu'il soit réellement envisagé de le faire au lycée.
avatar
Balthazaard
Esprit éclairé

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Balthazaard le Dim 1 Oct - 17:55
D'où mon interrogation qui reste print("Pas de solution") c'est mal... raise ValueError("Pas de solution") c'est bien....dans un cas on a un mécanisme compréhensible par un élève (même si il viole -momentanément- les bons principes de programmation) dans l'autre cas un processus, convenons le, opaque (si on a pas vraiment programmé, on est peu familier des exceptions) que l'on ne pourra jamais (comme tu l'as dit) expliquer correctement aux élèves...Franchement...

Pourquoi l'auteur n'assume t-il pas le côté "autiste" de sa fonction en filtrant la valeur interdite et en ne retournant rien...parce qu’on sent bien que là "il faut faire quelque chose.."

Un élève incapable en prépa de comprendre qu'une fonction "calcule" et n'affiche pas est mal barré pour appréhender la notion d'exception (surtout du concept de lever et de rattraper une exception)
e1654d
Niveau 6

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par e1654d le Dim 1 Oct - 18:08
Mais tout cela est sans objet : dans le contexte de cet article, il n'est pas du tout envisagé de faire écrire ou de montrer du Python aux élèves ; il est écrit à la fin que ça pourra être traduit en Python dans le sup, mais c'est tout, et c'est seulement dans ce tout dernier passage qu'il est question d'exception.

Et puis de toutes façons, visiblement, la présentation retenue pour le bac 2018 résout tous ces problèmes en faisant traiter un bout d'algorithme et en demandant la valeur de telle variable à la fin, ce qui évacue à la fois le problème de print et celui du concept de fonction. C'est assez judicieux pour une transition en douceur tenant progressivement compte de ce qui va se faire en seconde désormais.
Matheod
Niveau 9

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Matheod le Dim 1 Oct - 18:13
@Balthazaard a écrit:D'où mon interrogation qui reste   print("Pas de solution") c'est mal...   raise ValueError("Pas de solution") c'est bien....dans un cas on a un mécanisme compréhensible par un élève (même si il viole -momentanément- les bons principes de programmation) dans l'autre cas un processus, convenons le, opaque (si on a pas vraiment programmé, on est peu familier des exceptions) que l'on ne pourra jamais (comme tu l'as dit) expliquer correctement aux élèves...Franchement...

Pourquoi l'auteur n'assume t-il pas le côté "autiste" de sa fonction en filtrant la valeur interdite et en ne retournant rien...parce qu’on sent bien que là "il faut faire quelque chose.."

Un élève incapable en prépa de comprendre qu'une fonction "calcule" et n'affiche pas est mal barré pour appréhender la notion d'exception (surtout du concept de lever et de rattraper une exception)

Le plus simple serait simplement de retourner un tableau, qui peut contenir zéro, une ou deux solutions. Mais les tableaux ne sont pas au programme.

Mais cette histoire d'affichage est stupide. Tout dépend du but de la fonction.
Si son but c'est d'afficher les résultats alors le print est très bien.
Si son but est de retourner des résultats afin que cela serve dans un autre programme, le print n'a pas sa place c'est tout.

Et il est facile de trouver des exemples où on a besoin d'être dans le deuxième cas. Les élèves comprendront facilement que le print ne peut pas marcher !
avatar
Prezbo
Niveau 10

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Prezbo le Dim 1 Oct - 18:57
@Matheod a écrit:
@Balthazaard a écrit:D'où mon interrogation qui reste   print("Pas de solution") c'est mal...   raise ValueError("Pas de solution") c'est bien....dans un cas on a un mécanisme compréhensible par un élève (même si il viole -momentanément- les bons principes de programmation) dans l'autre cas un processus, convenons le, opaque (si on a pas vraiment programmé, on est peu familier des exceptions) que l'on ne pourra jamais (comme tu l'as dit) expliquer correctement aux élèves...Franchement...

Pourquoi l'auteur n'assume t-il pas le côté "autiste" de sa fonction en filtrant la valeur interdite et en ne retournant rien...parce qu’on sent bien que là "il faut faire quelque chose.."

Un élève incapable en prépa de comprendre qu'une fonction "calcule" et n'affiche pas est mal barré pour appréhender la notion d'exception (surtout du concept de lever et de rattraper une exception)

Le plus simple serait simplement de retourner un tableau, qui peut contenir zéro, une ou deux solutions. Mais les tableaux ne sont pas au programme.

C'est très exactement à ce quoi je pensais, plus haut, en écrivant "Je ne dis pas que c'est infaisable, mais ça me semble poser des problèmes qui risquent d'être au-delà des préoccupations d'un lycéen".


@Matheod a écrit:
Mais cette histoire d'affichage est stupide. Tout dépend du but de la fonction.
Si son but c'est d'afficher les résultats alors le print est très bien.
Si son but est de retourner des résultats afin que cela serve dans un autre programme, le print n'a pas sa place c'est tout.

Et il est facile de trouver des exemples où on a besoin d'être dans le deuxième cas. Les élèves comprendront facilement que le print ne peut pas marcher !

Je surinterprète peut-être, mais j'ai l'impression que l'esprit des dernières instructions (si elles sont effectivement diffusées à tous, au passage) et bien de penser systématiquement et terme de fonctions...C'est peut-être une bonne habitude de programmation, mais est-ce présentable sans avoir quelques notions préalables ? (Concernant par exemple la programmation impérative, le typage, la manipulation des listes, ou la simple notion de retour d'un programme...)

Une remarque : j'ai potassé ces derniers mois (plus ou moins profondément) quelques tutos et livres sur Python. Je ne crois pas en avoir trouvé un qui commence directement par la programmation fonctionnelle.
Matheod
Niveau 9

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Matheod le Dim 1 Oct - 19:14
Le programme en lui même n'impose pas le fait de passer par les fonctions.
Quant au document d'accompagnement, il est bien écrit que c'est à destination des enseignants pour leur montrer les possibilités de python (de toute façon on le voit bien que ce n'est pas pour des élèves au vu de la complexités des situations proposés).

Donc en gros, rien n'impose de passer par des fonctions.

Perso j'ai choisi une trame très progressive où les fonctions n'arrivent qu'une fois que le reste est maîtrisée.
avatar
VinZT
Expert

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par VinZT le Dim 1 Oct - 20:29
@Matheod a écrit:Le programme en lui même n'impose pas le fait de passer par les fonctions.

Ben si, un peu quand même :



J'ai bien peur, avec cette histoire de fonctions, qu'on passe d'un dogme à un autre.

Les cours en ligne sur python (j'en avais suivi un du MIT, plutôt bien fichu), notamment américains (gens réputés pragmatiques), ne s'embarrassent pas trop de telles subtilités.

_________________

« Il ne faut pas croire tout ce qu'on voit sur Internet » Victor Hugo.
« Le con ne perd jamais son temps. Il perd celui des autres. » Frédéric Dard
« Ne jamais faire le jour même ce que tu peux faire faire le lendemain par quelqu'un d'autre » Pierre Dac
« Je n'ai jamais lâché prise !» Claude François
« Un économiste est un expert qui saura demain pourquoi ce qu'il avait prédit hier ne s'est pas produit aujourd'hui. » Laurence J. Peter
avatar
Balthazaard
Esprit éclairé

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Balthazaard le Dim 1 Oct - 20:43
J'ai toujours l'impression qu'un clan impose ses vues avant d'être remplacé par un autre et ainsi de suite.
Et si après on programme dans un langage qui n'est pas fonctionnel, par ex en java, on fait quoi?
Contenu sponsorisé

Re: (maths) Formation aux aménagements du programme de seconde : algo/programmation

par Contenu sponsorisé
Voir le sujet précédentRevenir en hautVoir le sujet suivant
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum