Algobox - Euclide

[paspythagore]

Bonjour,

je cherche à programmer le pgcd sous le modèle de l'algorithme d'Euclide avec Algobox.

J'en suis là :

Code : Tout sélectionner

VARIABLES
  A EST_DU_TYPE NOMBRE
  B EST_DU_TYPE NOMBRE
  R EST_DU_TYPE NOMBRE
DEBUT_ALGORITHME
  LIRE A
  LIRE B
  R PREND_LA_VALEUR A%B
  TANT_QUE (B!=0) FAIRE
    DEBUT_TANT_QUE
    SI (A>=B) ALORS
      DEBUT_SI
      R PREND_LA_VALEUR A%B
      A PREND_LA_VALEUR B
      B PREND_LA_VALEUR R
      FIN_SI
      SINON
        DEBUT_SINON
        A PREND_LA_VALEUR B
        B PREND_LA_VALEUR A
        FIN_SINON
    FIN_TANT_QUE
  AFFICHER A
FIN_ALGORITHME

Ce code marche bien si je saisi 2214 puis 156 ou 8 puis 4 mais ne convient pas si je saisi 156 puis 2214.

Comment faire ?

[rebouxo]

Parce qu'il faut toujours diviser le plus grand par le plus petit. Or tu ne testes pas cette éventualité sur tes données.

Olivier

[paspythagore]

Bonjour,

Je voulais avec mon si non inverser A et B et que l'algorithme "redémarre" :

Code : Tout sélectionner

SINON
        DEBUT_SINON
        A PREND_LA_VALEUR B
        B PREND_LA_VALEUR A
        FIN_SINON

[rebouxo]

Oui, et tu le fait quand tu rentres dans ta boucle tant que. Mais, il faudrait vérifier que les a > b avant d'entrer dans la boucle.

Olivier

[paspythagore]

Aïe, aïe, aïe, je tourne en rond,

ça ne marche toujours pas :

Code : Tout sélectionner

VARIABLES
  A EST_DU_TYPE NOMBRE
  B EST_DU_TYPE NOMBRE
  R EST_DU_TYPE NOMBRE
DEBUT_ALGORITHME
  LIRE A
  LIRE B  
  	SI (A<B) ALORS
  		DEBUT_SI
        A PREND_LA_VALEUR B
        B PREND_LA_VALEUR A
  			R PREND_LA_VALEUR A%B
  		FIN_SI
   				TANT_QUE (B!=0) FAIRE
    				DEBUT_TANT_QUE    
      			R PREND_LA_VALEUR A%B
      			A PREND_LA_VALEUR B
      			B PREND_LA_VALEUR R
    				FIN_TANT_QUE
    	
  AFFICHER A
FIN_ALGORITHME

[rebouxo]

Comme quoi algobox n'est vraiment pas adapter à l'apprentissage de l'informatique...

Essayons de décrire dans le langage courant (et pas dans un langage informatique) ce que l'on veut faire.

On demande a et b.

Si a < b, alors a prend la valeur de b et b prend la valeur de a.

ensuite on fait l'algo d'Euclide.

Or toi, tu ne fais l'algo d'Euclide que si tu inverse a et b. Ce sont deux étapes différentes. L'algo d'Euclide suppose que a > b, donc il faut s'assurer que a > b avant de le faire.

Une question naïve : pourquoi utilises-tu algobox ?

Olivier

[texmaker]

Comme quoi algobox n'est vraiment pas adapter à l'apprentissage de l'informatique...

Essayons de décrire dans le langage courant (et pas dans un langage informatique) ce que l'on veut faire.

On demande a et b.

Si a < b, alors a prend la valeur de b et b prend la valeur de a.

ensuite on fait l'algo d'Euclide.

Or toi, tu ne fais l'algo d'Euclide que si tu inverse a et b. Ce sont deux étapes différentes. L'algo d'Euclide suppose que a > b, donc il faut s'assurer que a > b avant de le faire.

Une question naïve : pourquoi utilises-tu algobox ?

Olivier

Sa haute magnificence Olivier Reboux au lieu de dire "beurk cra cra" envers tous les logiciels qui ne lui plaisent pas* ne se rend même pas compte que "a prend la valeur de b et b prend la valeur de a" n'a jamais permis d'échanger la valeur de 2 variables. C'est pourtant la base en algorithmique...Mais il est vrai que du haut de sa grandeur et de son arrogance on a du mal à voir ces petits détails.

*viewtopic.php?p=139046#p139046
viewtopic.php?p=98700#p98700

[texmaker]

Aïe, aïe, aïe, je tourne en rond,

ça ne marche toujours pas :

Pour en revenir au fond du problème :
1) L'algo d'euclide est dans les exemples fournis avec algobox. Menu "Fichier" -> "Ouvrir un exemple" -> prof_pgcd_euclide.alg
2) Il n'est pas forcément nécessaire de tester quel est le plus grand des deux nombres pour trouver le pgcd avec l'algo d'euclide.
Ce code là marche si A<B ou A>=B

Code : Tout sélectionner

1     VARIABLES
2       A EST_DU_TYPE NOMBRE
3       B EST_DU_TYPE NOMBRE
4       R EST_DU_TYPE NOMBRE
5     DEBUT_ALGORITHME
6       LIRE A
7       LIRE B
8       AFFICHER "Le PGCD de "
9       AFFICHER A
10      AFFICHER " et "
11      AFFICHER B
12      AFFICHER " est : "
13      TANT_QUE (B!=0) FAIRE
14        DEBUT_TANT_QUE
15        R PREND_LA_VALEUR A%B
16        A PREND_LA_VALEUR B
17        B PREND_LA_VALEUR R
18        FIN_TANT_QUE
19      AFFICHER A
20    FIN_ALGORITHME

3) Pour échanger le contenu de deux variables, on utilise en général une troisième variable (sauf langage particulier, mais là ce n'est plus de l'algo mais de la programmation qui utilise une spécificité d'un langage particulier).
C'est expliqué dans la brochure "algorithmique en première avec algobox" page 45 ( brochure disponible ici : http://www.xm1math.net/algobox/algobook.html )

[paspythagore]

Merci à tous les deux,

je ne veux pas déclencher de polémique.

De manière plus stricte, pour échanger les valeurs, j'ai effectivement appris à faire ça :

Code : Tout sélectionner

VARIABLES
  A EST_DU_TYPE NOMBRE
  B EST_DU_TYPE NOMBRE
  C EST_DU_TYPE NOMBRE
  D EST_DU_TYPE NOMBRE
  R EST_DU_TYPE NOMBRE
DEBUT_ALGORITHME
  LIRE A
  LIRE B
  SI (A<B) ALORS
    DEBUT_SI
    C PREND_LA_VALEUR A
    D PREND_LA_VALEUR B
    A PREND_LA_VALEUR D
    B PREND_LA_VALEUR C
    R PREND_LA_VALEUR A%B
    FIN_SI
  TANT_QUE (B!=0) FAIRE
    DEBUT_TANT_QUE
    R PREND_LA_VALEUR A%B
    A PREND_LA_VALEUR B
    B PREND_LA_VALEUR R
    FIN_TANT_QUE
  AFFICHER A
FIN_ALGORITHME

Pour l'algorithme d'Euclide A>B mais pas pour le pgcd (A, B) pas forcément, enfin, je crois...

Je fais de l'Algobox parce que c''est le programme de mes enfants.

[rebouxo]

@papsythagore : ce qui suit ne te concerne pas. Cela dit j'aimerais bien savoir pourquoi tu utilises algobox ? D'ailleurs texmaker aussi cela lui fera de la pub.

Comme quoi algobox n'est vraiment pas adapter à l'apprentissage de l'informatique...

Essayons de décrire dans le langage courant (et pas dans un langage informatique) ce que l'on veut faire.

On demande a et b.

Si a < b, alors a prend la valeur de b et b prend la valeur de a.

ensuite on fait l'algo d'Euclide.

Or toi, tu ne fais l'algo d'Euclide que si tu inverse a et b. Ce sont deux étapes différentes. L'algo d'Euclide suppose que a > b, donc il faut s'assurer que a > b avant de le faire.

Une question naïve : pourquoi utilises-tu algobox ?

Olivier

Sa haute magnificence Olivier Reboux au lieu de dire "beurk cra cra" envers tous les logiciels qui ne lui plaisent pas* ne se rend même pas compte que "a prend la valeur de b et b prend la valeur de a" n'a jamais permis d'échanger la valeur de 2 variables. C'est pourtant la base en algorithmique...Mais il est vrai que du haut de sa grandeur et de son arrogance on a du mal à voir ces petits détails.

SI parfaitement ta sainteté, je l'ai parfaitement vu et je l'ai fait sciemment, parce que le problème n'est pas comment ont fait cet échange, mais qu'il fallait bien faire la distinction entre les deux étapes. Mais bon, il fallait bien qu'un troll sorte de son bois, je te remercie de me donner l'occasion de le nourrir. Savoir découpé un problème en étapes fondamentales est la première tâche à laquelle on doit s'attacher lorsque l'on veut programmer. Est-ce de l'algorithmique. Vraiment je n'en sais rien, par contre un bon vieux fond de cartésianisme, ça c'est sur.

J'aime bien grandeur et arrogance, cela fait du bien à mon petit ego flapi. Vas-y continue, c'est bon.

Il me semble que l'on a encore le droit d'avoir une opinion. Le jour ou je serais dictateur en chef de l'univers et du reste, on en reparlera

Maintenant, oui je déteste scratch. Pour moi, ce truc méprise les élèves en supposant qu'il suffit de mettre de la couleur (criarde en plus, mais c'est un autre débat) et en rendant la connaissance soit-disant (parce que pour moi c'est assez repoussant) attractive par des gadgets : boutons, couleurs,...

L'aspect d'un logiciel (ou d'un livre, parce que ce que je dénonce n'est, malheureusement pas spécifique à scratch) ne doit pas être primordiale dans l'apprentissage. Note bien qu'ici je fait une hypothèse qu'il faudrait certainement tester de manière scientifique (test en double aveugle et compagnie). Ce qui est en jeu ici (à mon avis à moi que j'ai personnellement) ce sont des processus de compréhension et d'adaptation aux objets technologique. Je crains (ici c'est une hypothèse, mais pour voir pas mal de monde devant un clavier et une interface graphique, je suis un peu plus sur de moi, mais bon disons qu'il y a de la place à un doute) que le clic soit beaucoup moins porteur de sens (qu'est-ce qui se passe dans la machine, l'effet magique) que l'écriture. L'écriture ne supprime pas tous les obstacles comme dirait Gaston B., mais je pense que l'interface presse bouton en rajoutent pas mal. Aux obstacles de la notion de programmes et d'algorithmes se rajoutent ceux inhérent à l'interface. Ceci est prouvé : c'est ce que reproche les utilisateurs aux changements d'interface d'ubuntu, entre autre). Il ne s'agit pas simplement d'un changement d'habitude, il faut refaire ses cartes mentales du mode de fonctionnement de l'environnement.

Voilà c'est en gros pour cela que je déteste scratch (et algobox, mais pour te rassurer tu as fait des progrès, il est beaucoup mieux qu'avant, en tous les cas beaucoup mieux que scratch). Après le temps d'apprentissage étant limité, il va bien falloir qu'on essaye d'être productif. Pourquoi ne pas vouloir apprendre un langage de programmation, réellement utilisé, avec une vrai base d'utilisateur, qui soit indépendant d'une interface imposée ? Là mystère et boule de gomme?

Olivier
Vaincu par le syndrome tweeter, il a voulu faire court... Valérie sauve-moi !
(voir les liens aimablement fournis par Texmaker, qui doit mieux connaître le fond de ma pensée que moi-même)

[François D.]

Bigre ... le débat s'anime un peu. Un peu en vrac, je me permets d'apporter quelques éléments de réflexion personnels.

Je suis aussi de ceux que l'esthétique « flashy les coloris » agace prodigieusement ; j'en ai même fait un critère de sélection (pas prioritaire, mais non négligeable) lorsqu'il s'agit de choisir un nouveau manuel : l'aspect bigarré se fait toujours au détriment d'un organisation claire et structurée du bouquin, un comble en maths.

Pour ce qui est de l'algorithmique : en reste-t-on au langage (pseudo-)naturel ou faut-il passer à un langage de programmation, et si oui lequel ?
Je dois dire que je suis en train d'évoluer sur le sujet.
Jusqu'à présent, je trouvais idiot de ne pas passer à la phase programmation, et j'utilisais Python car c'est un langage généraliste qu'on peut réinvestir dans d'autres domanines que les maths. Cela dit, je me rends compte que ce faisant, on risque d'accumuler les strates de difficulté : il y a d'abord l'algorithme à mettre au point, et ensuite sa mise en musique qui se doit de respecter la syntaxe du langage choisi. Or, comme le dit rebouxo, un des grands problèmes est de faire en sorte que les élèves apprennent à décomposer des tâches courantes (ou censées l'être ) en étapes élémentaires : outre que c'est souvent pour eux une nouveauté, cela suppose de bien maîtriser la tâche en question ; en trouver devient denrée rare ... Une fois qu'on a passé la phase, primordiale, de l'élaboration théorique de l'algorithme, il faut le tester pour le valider. Et là, si vous devez en plus gérer les bizarreries syntaxiques du langage choisi (chacun a les siennes), vous ne faites que brouiller le message. Conclusion possible : AlgoBox, au moins au début ... ?

Enfin, le débat sur les interfaces graphiques vs. ligne de commnde (pour schématiser), etc. Je vais ici recycler des arguments déjà rodés IRL auprès d'amis . En gros, je dis qu'une interface graphique est pratique pour faciliter d'un point de vue ergonomique un certain nombre de tâches standardisées (copier des fichiers, en ouvrir avec une application déterminée, etc.), mais qu'elle ne peut pas suffire pour des choses plus complexes et fines. La mystification consiste à faire croire que l'utilisation d'un ordi peut se réduire à ce qu'une interface graphique sait faire correctement.
GeoGebra est un bon exemple : j'utilise les boutons, menus, etc. pour les objets et constructions de base, mais un grand nombre de possibilités n'est accessible que via une commande à saisir dans la zone prévue à cet effet.

[rebouxo]

Si je puis me permettre Algobox à lui aussi c'est bizarrerie syntaxique, donc l'argument ne permet pas de choisir. Le reste je suis assez d'accord avec toi.

La seule chose qui à mon avis se discute très sérieusement, c'est de penser qu'il y a un ordre dans l'apprentissage. D'abord l’algorithmique puis la programmation (ou l'inverse d'ailleurs). Je pense que les deux doivent sont interdépendants. Cela ne résout pas la question du choix du langage. Les arguments doivent se situer à un autre niveau.

Olivier

[François D.]

AlgoBox a effectivement ses bizarreries syntaxiques, mais au moins les élèves n'ont pas réellement besoin de les apprendre : on clique sur les menus/options désirés, et le « code » est généré tout seul 8) .

Pour ce qui est de l'articulation algorithme/programmation dans un langage ... D'abord je pense que si une réponse simple et claire existait, elle aurait déjà été trouvée . Ensuite, j'ai tendance à me méfier des programmes trop « astucieux » en ce sens qu'ils exploitent de manière trop poussée les spécificités d'un langage, au point d'en devenir intransposables ; en rester, dans un premier temps, à des algorithmes en langage (pseudo-)naturel limite ce genre de dérive : ainsi, on est mieux préparé à apprendre à programmer (tout court), et pas seulement à programmer en Python, en C, etc. Enfin, c'est comme ça que je le vois.

Cela dit, je n'arrive pas à m'empêcher de penser que ces histoires d'algorithmique à toutes les sauces n'auront qu'un temps, comme tout effet de mode ... ou bien ?

EDIT : pour le choix d'un langage ... je me souviens d'un truc/machin/bidule appelé LSE pour « Langage Spécial Éducation »
http://fr.wikipedia.org/wiki/LSE_%28lan ... mmation%29, qui avait été utilisé un temps lorsqu'une option informatique/programmation avait été proposée au Bac (que j'ai eu en 1989) : mon prof de l'époque avait commencé avec ça, mais avait vite basculé vers le Pascal (pour lequel j'ai depuis cette époque une certaine tendresse ), et nous avait même fait faire un peu de Prolog (très intéressant, mais atypique).

[rebouxo]

Oui, d'ailleurs si algo et programmation vont de pairs c'est particulièrement difficile de faire la distinction. Je vois cela comme une dialectique, l'un faisant progresser l'autre. Vraiment très intriqué. Le matheux est certainement satisfait par un algo en langage plus ou mois naturel, mais sans passage sur la machine, cela ne sert à rien. Et c'est en passant à la réalisation pratique que tout un tas de problèmes surgissent. Je me souviens d'un programme en stat pour représenter le plan en composant principale de quatre points dans l'espace. Mon algo de matheux fonctionné en théorie (matrice de rotations), c'était sans compté avec la machine...

olivier

[paspythagore]

Bonsoir,

sans avoir la prétention d'être au niveau pour pouvoir entrer dans la polémique, je souhaiterai savoir qu'est ce qu'il y a d'autre dans l'informatique que les algorithmes.

Pour moi l'informatique c'est d'abord un langage réduit à des oui et des non avec lesquels on construits des boucles (algorithmes) pour calculer, rechercher, différencier, etc.

Et le pgcd est un exemple de programme informatique historique.

Mais, même si je le répète, je suis novice, je souhaiterai comprendre vos arguments allant contre.

Comme je le disais je fais de l'Algobox parce que c'est au programme de mes enfants.

Bonne soirée.

[paspythagore]

Oulà, si même le modérateur qui habituellement me corrige est fatigué...

Mon algo de matheux fonctionné en théorie (matrice de rotations), c'était sans compté avec la machine...

[Arnaud]

sans avoir la prétention d'être au niveau pour pouvoir entrer dans la polémique, je souhaiterai savoir qu'est ce qu'il y a d'autre dans l'informatique que les algorithmes.

L'informatique est un domaine qui regroupe beaucoup de notions, et pas seulement les programmes et leurs algorithmes.

Pour moi l'informatique c'est d'abord un langage réduit à des oui et des non avec lesquels on construits des boucles (algorithmes) pour calculer, rechercher, différencier, etc.

Voir plus haut, l'informatique n'est pas un langage, mais le moyen d'analyser/traiter des données, soit en programmant un outil d'analyse, soit en utilisant un programme déjà conçu à cette fin.

Et le pgcd est un exemple de programme informatique historique.

C'est un algorithme. La discussion qui a lieu plus haut fait la distinction entre l'algorithme et le programme. En gros l'algorithme est la recette de cuisine, et le programme est la façon de mettre cette recette de cuisine en oeuvre et la question posée est : faut-il seulement inculquer la capacité d'élaborer une recette une cuisine ou aussi apprendre aux élèves à la mettre en oeuvre ?

Comme on est presque vendredi, je vais fournir deux réponses persos :

1) Oui, je préfère faire faire la cuisine à mes élèves, et je crois qu'ils aiment ça ces petits gourmands,

2) Ca sert à rien de se prendre le chou à cause d'un programme volontairement vague de l'EN. En laissant les choix ouverts de cette façon, on voit tout et n'importe quoi. Comme d'hab, il a fallu un nombre d'années trop importants pour qu'elle se lance dans l'informatique, et ce par le biais d'un bidouillage hallucinant. L'informatique et ses conséquences doivent maintenant faire l'objet d'un cours à part entière, indépendant des autres matières.

[texmaker]

Le problème est d'abord pédagogique et les données du problème sont claires :
- il y a un programme qui est tout à fait clair et les questions posées au bac l'ont très bien montrée (quelques soient leurs défauts, ces questions ont eu au moins ce mérite). Il suffit de lire le BO : c'est bien l'algorithmique qui est au programme (le BO dit clairement qu'il ne faut réaliser que quelques programmes avec un logiciel). Et les seules structures au programme ont toujours été affectation, calcul, entrée, sortie, instruction conditionnelle, calcul itératif et boucle avec test d'arrêt. Un point, c'est tout. D'ailleurs on a même appris que les listes ne seront jamais pas utilisées dans les questions au bac. Par contre ce qui est au programme c'est d'analyser et de faire tourner à la main des algos (tous les programmeurs savent qu'un algo, ça se conçoit d'abord sur papier) : il n'y a besoin d'aucun logiciel pour cela (algobox compris) et ça qui tombe au bac.
- le programme d'algorithmique doit s'adresser à TOUS les élèves (soit près de 600 000 par cohortes) et pas à une minorité (sans oublier les 20 000 professeurs concernés) et ce en lien direct avec le programme de mathématique (il n'a jamais été question de faire de la programmation pour la programmation).
- quel pourcentage de professeurs a reçu une formation et se sentent à l'aise avec l'algo? (et non, tous les professeurs ne sont pas des geeks passionnés de programmation )
- quel pourcentage réel d'élèves ont vraiment eu de l'algo? (pour la classe de seconde, on peut même trouver une estimation plus ou moins officielle sur internet)
- quel pourcentage de profs connaissent python et l'ont même installé chez eux? 1%, 5% au grand maximum?
- quel pourcentage d'élèves ont installé python chez eux? 0,1%?
- que se passera-t-il au bac, si un candidat sort une "pythonnerie" (terme utilisé chez les programmeurs pour indiquer une instruction spécifique au langage python - ça n'a rien de péjoratif : c'est du jargon - et c'est la même chose pour tous les langages y compris celui d'algobox), comme une affection simultanée. Et bien, il faut le dire clairement sans langue de bois : sa réponse sera compté fausse.
- à quoi assiste-t-on depuis l'introduction de l'algo dans les programmes, sinon à une débauche de publication sur internet d'articles et de ressources hors programme où l'ont fait de la programmation de la programmation sans aucun lien avec le programme de maths et ce quelque soit le logiciel ou le langage utilisé (je peux témoigner, que même avec algobox, des élèves ou des collègues m'ont demandé de l'aide sur des algos qui n'avaient pas le moindre rapport avec le programme officiel d'algo ou de math ....)
- le résultat du manque de formation adaptée pour les profs, de l'absence de pilotage et de réflexion pédagogique et de course effrénée au "plus geek que moi tu meurs", on l'a eu cette année au bac puisque des statistiques ont été faites lors de la correction du bac sur les questions d'algo. Il est interdit de divulguer le détail des chiffres, mais comme il était prévisible les résultats sont très mauvais. Même une large majorité de l'élite (les spé maths de TS) ne comprend pas la notion de boucle.
Dès lors le choix pédagogique va être très clair pour les années futures :
- soit on continue comme maintenant les "geekeries hors programme" et les concours de "programmation pour la programmation" en ne s'adressant qu'à une minorité et l'algorithmique continuera à être marginalisée et délaissée par une majorité d'élèves (et par une partie des professeurs).
- ou on se recentre sur ce qu'il y a réellement au programme avec un vrai souci pédagogique de s'adresser à TOUS les élèves.
Le fiasco qui a pu être mesuré de façon objective au bac cette année (au moins avec les chiffres, même officieux, on a une petite chance de sortir de la méthode coué et bon nombre de responsables, à tous niveaux, vont peut-être redescendre "sur terre") , la problématique va peut-être enfin quitter l'aspect technique pour aborder le problème de fond qui est de nature pédagogique (90% des élèves et des profs n'ont que faire des trolls techniques entre geeks sur les logiciels et les langages).

Pour finir une petite anecdote qui montre bien la différence de fond qu'il y a entre entre algo et programmation. Les responsables d'une UV d'algorithmique à l'université de Bordeaux avait mis l'avertissement suivant (assez brutal) aux étudiants sur la page web présentant la formation (je cite de mémoire : la formulation n'était pas exactement la même, mais c'était en gros ça ) :
1) Vous n'aurez accès à aucun ordinateur avant plusieurs mois
2) Vous ne programmerez aucun jeu
3) Vous ferez des maths

[rebouxo]

Tiens je suis d'accord avec toi. Tu as parfaitement raison : manque de formation des enseignants, mauvais cadrages, délire geek, aucune réelle réflexion pédagogique, didactique et épistémologique sur ce les changements dans la nature des maths que l'introduction de l'algorithmique vont nécessairement amener. Ce dernier point est particulièrement important. Et sur l'académie de Rouen absolument pas évoqué. Cela dit l'absence de choix d'un langage permet de troller pas mal (on est d'accord la dessus ) et de ne pas se concentrer sur l'essentiel (cela dit je maintiens que le temps de formation étant limité, il faut faire ce choix, et que ce choix ne peut pas se faire uniquement sur des critères pédagogiques et internes aux maths, mais doit déborder le cadre de la matière.).

Le choix même d'appeler cela algorithmique est très critiquable. C'est quoi l'algorithmique : efficience (l'algo fait-il ce qu'il est sensé faire), efficacité (le fait-il vite ou non). Mais ce ne sont pas de simples questions théoriques. Un moment, il faut aussi passer sur la machine (voir l'exemple dans mon post précédent ou bien le calcul de $\pi$ par Guillaume Connan (BV de l'APMEP n°495) pour voir qu'une joli expérience de pensée n'a pas toujours d'intérêt pratique, ou bien ne se comporte pas comme prévu. Pour donner un dernier exemple : à quoi sert de connaître le crible d'Eratostène, puisqu'en pratique il n'a aucun intérêt. "Calculs automatisés, approchés" aurait été moins ambiguë, car cela aurait restreint le terrain de geekerie et recentrer sur des problèmes de maths. Mais bon on ne va pas refaire l'éducation nationale. Bref passer par la machine n'est pas qu'une simple étape qui ne servirait à rien. Elle est aussi source de compréhension (pourquoi fait-on ceci, plutôt que cela). Je reste aussi persuadé que certains élèves (malheureusement pas tous) ont besoin de faire pour comprendre. Un simple travail sur papier n'est là pas du tout formateur.

Lors d'une journée de (pseudo ? en une journée on ne peut pas tout faire) formation sur les nouveaux programmes de première (toutes séries confondues...) l'après midi fut consacrée à l'algorithmique et on est rapidement parti vers des délires de programmation (tout cela sous algobox, enfin sauf deux ou trois). Aucune réflexion sur le rôle et la place de l'algo, aucun cadrage de la part de l'inspection, aucune réflexion sur ce que cela apporte (ou pas) aux mathématiques. Réflexion d'un des formés : "oui, bon ben c'est pas des maths, je n'en ferais pas".

Concernant les résultats des élèves au bac. Il me semble un peu tôt pour faire une évaluation de la réforme. On va dire que les résultats montrent juste d'où on part. Bref, avant de jeter la réforme, il serait souhaitable d'attendre un peu. De voir ce que seront les futurs épreuves du bac (en STI pas de sujet 0 en maths, on va rigoler l'an prochain).

Olivier
Merde, et moi qui croyait que l'on aller troller. Zut, alors

[Arnaud]

Dans la mesure où j'écris moi même des programmes d'enseignement, j'ai lu un bon nombre de fois ceux publiés en France, notamment :

Dans le cadre de cette activité algorithmique, les élèves sont entraînés :
• à décrire certains algorithmes en langage naturel ou dans un langage symbolique ;
• à en réaliser quelques uns à l’aide d’un tableur ou d’un petit programme réalisé sur une calculatrice ou avec un logiciel
adapté ;
• à interpréter des algorithmes plus complexes.
Aucun langage, aucun logiciel n’est imposé.

En gros, chacun fait ce qu'il veut. Et ça pour moi, c'est tout sauf clair. Je ne parle même pas de ceux qui se lancent dans java.
Je suis d'accord sur le fait que personne n'a été formé pour cela, qu'un élève sortant une astuce de programmation ne sera pas forcément reconnu en ce sens, et même pour d'autres choses que tu racontes. Mais, enseigner un langage de programmation ne signifie pas que toutes les réponses des élèves se feront toujours avec ce langage, cela revient au prof de leur demander aussi du pseudo-code.