Mathématice, intégration des Tice dans l'enseignement des mathématiques  
Sommaire > N° 1 - Septembre 2006 > Articles publiés en avance > Programmation visuelle dynamique en analyse (...)

Programmation visuelle dynamique en analyse avec SofusGeo
Moteur de recherche

A) Introduction

De nombreux problèmes d’analyse peuvent être illustrés par des programmes dynamiques, comme le montre cet article où ils sont classés par thèmes : extremum et optimisation, suites, calcul infinitésimal.

Mais comment créer de tels programmes si on n’est pas un enseignant expert en programmation dynamique ? Et puis, au lieu de fournir aux élèves des programmes prêts à l’emploi, peut-on les faire travailler sur l’élaboration de ces programmes puisque l’enseignement du codage fait partie depuis quelques années du métier d’enseignant de mathématiques ? Ce sont à de telles interrogations que je vais tenter d’apporter des réponses dans cet article.

Comme support logiciel, j’utiliserai SofusGeo, un outil permettant de faire de la programmation dynamique soit avec des blocs, soit textuellement. A l’origine, SofusGeo a été créé pour promouvoir l’enseignement de l’algorithmique dans un cadre géométrique (voir article). Ici, c’est l’intérêt mathématique (en analyse) des activités qui a été privilégié dans leur choix. Mais, quand elles se prêtent naturellement à des exercices d’algorithmique, cela sera évidemment mis en avant.

Les activités présentées n’ont pas été testées en classe, n’enseignant pas en lycée, mais leur contenu mathématique s’inspire fortement de plusieurs documents Eduscol relatifs à l’enseignement de l’analyse au lycée. Je remercie Patrice Debrabant pour sa participation à l’élaboration de cette liste d’exemples, ainsi que pour les idées d’évolutions de SofusGeo qu’il m’a données : sa grande connaissance de DGPad, le logiciel sur lequel s’appuie SofusGeo, a été une aide très précieuse.

On peut accéder à SofusGeo à partir de ma page web consacrée à Blockly (voir lien). Plusieurs exemples de cet article peuvent y être directement testés (menu « Démos », sous-menu « Analyse »).

B) De la programmation classique à la programmation dynamique

A l’exception d’un menu intitulé « DGPad [1] », tous les menus de SofusGeo permettent de faire de la programmation visuelle « classique ». Cela permet donc de traiter de façon usuelle un problème d’analyse tel que le calcul approché d’une intégrale par la méthode des rectangles :

Ce programme par blocs peut être exécuté directement (bouton « Exécuter ») ou être traduit en Javascript (bouton « Editeur »). Comme Python est le langage de programmation « fortement recommandé » [2] au lycée, je ne m’attarderai pas sur la programmation textuelle avec SofusGeo.

Comme je le détaillerai ultérieurement, les deux fonctions Blockly (f et integrale) peuvent aussi être utilisées dans le cadre d’une activité dynamique sur la méthode des rectangles :

La courbe en bleu, dessinée sur un intervalle défini dynamiquement par deux curseurs, représente l’intégrale calculée avec la méthode des rectangles. La valeur de l’aire délimitée par les deux traits verticaux verts, la courbe rouge et l’axe des abscisses, est affichée dynamiquement en dessous des deux curseurs.

Les secrets de fabrication seront dévoilés un peu plus tard dans l’article. En attendant, en voici quelques uns présents dans de nombreux exemples, et qui permettent de donner un premier aperçu des compétences à acquérir pour concevoir des programmes dynamiques adaptés à l’analyse :

Les deux premiers blocs définissent deux curseurs variant entre -4 et 4, et fixent la position où ils sont affichés. L’introduction de curseurs (ou d’objets géométriques) conduit à délaisser le traditionnel bloc d’affichage et à utiliser un bloc « Expression » pour afficher la valeur de l’intégrale.

C) Extremum et optimisation

Histoire de parabole

Cet exemple s’inspire d’une activité Eduscol proposée pour des lycéens de première S, dont voici un extrait de la fiche élève :

Pour aborder ce TP avec SofusGeo, on peut songer à fournir [3] ce programme initial aux élèves pour qu’ils le testent :

A l’exécution, les élèves s’apercevront qu’ils peuvent faire varier le curseur et que le point (xMin, f(xMin)) n’est pas le sommet de la parabole :

Donc, les élèves seront conduits à modifier la valeur de l’expression xMin. Lorsqu’ils auront trouvé la solution (-b/4), on peut les inviter à rechercher l’équation de la trajectoire du sommet de la parabole lorsque b varie. Pour les y aider, on peut leur proposer de rajouter un bloc affichant la trace du sommet, d’exécuter le programme et de faire varier le curseur :

Aires égales

Cet exemple s’inspire d’une activité Eduscol, qui est une adaptation d’un sujet de bac (section ES-L) dont voici un extrait :

La figure accompagnant cet énoncé de bac est donnée ci-dessous en partie gauche, tandis que la partie droite provient de l’exécution d’un programme SofusGeo qui sera ensuite présenté :

L’aire du quadrilatère OABC est affichée dans une expression dépendant de la valeur du curseur « a ». On peut constater, dans la dernière instruction ci-dessous, que le champ « valeur » de l’expression est rempli d’une façon qui peut déconcerter les lecteurs ne connaissant pas DGPad : « OABC » désigne en effet le nom du quadrilatère, mais c’est bien l’aire [4] du quadrilatère qui est affichée.

Il reste à compléter le programme pour obtenir la courbe en orange, qui représente l’évolution de l’aire en fonction de la valeur du curseur. Elle apparaît uniquement quand la valeur du curseur est modifiée, et résulte de la trace laissée par le point lieu(a, aire_OABC), selon une technique qui a été introduite dans l’exemple précédent (lieu du sommet d’une parabole).

Cet exemple ne me semble pas pouvoir déboucher sur un prolongement algorithmique, tout comme celui illustrant la dérivation ultérieurement : pas grave, la priorité d’un enseignant de mathématiques étant (jusqu’à nouvel ordre) d’enseigner les mathématiques !

Complément

Dans le cas de la parabole, l’extremum peut être déterminé explicitement. Mais comment procéder dans un cas plus général, où on doit en calculer une valeur approchée avec un programme ? Il suffit de remplacer le bloc « Point » définissant le sommet par un bloc plus général, qui calcule cette valeur approchée en balayant l’intervalle des abscisses avec un pas fixe (ici 0.01) :

Le choix de l’intervalle des abscisses (ici [-5, 5]), dans lequel doit se trouver le minimum quelle que soit la valeur du curseur « b », est à déterminer expérimentalement : on fait varier le curseur, on observe la courbe…

Le calcul de xMin doit être effectué à l’intérieur du bloc Point, alors que d’un point de vue algorithmique il serait plus naturel de l’effectuer auparavant : donc, si on veut faire travailler les élèves sur l’élaboration de l’algorithme calculant le minimum, il faut veiller à bien leur préciser l’endroit où ils doivent insérer les blocs.

D) Suites

Suite récurrente

Cet exemple, très classique, illustre la convergence d’une suite récurrente de la forme un+1 = f(un), où f(x) = 0.8 x + 12. En augmentant la valeur du curseur « n », on constate que la suite semble converger vers 60, solution de l’équation f(x)=x :

La courbe en bleu est obtenue comme affichage d’une liste de points, c’est à dire une liste de listes de longueur 2 :

Il reste quelques détails à fignoler, comme l’affichage de la droite d’équation y = x ou le réglage du pas du curseur « n » à 1 pour que les valeurs prises par n soient toutes entières.

Il me semble problématique de faire travailler les élèves sur l’élaboration de ce programme gérant une listes de listes. Néanmoins, comme l’utilisation de curseurs est attractive, on peut peut-être envisager une activité algorithmique plus simple, consistant à afficher le terme d’ordre n à l’aide d’une expression :

Jeu de nombres

Ce second exemple sur les suites est beaucoup plus original que le premier. Avant de le détailler, voici comment il est justifié pédagogiquement dans le document Eduscol dont il est issu :

Il s’adresse à des élèves de première et sa place indiquée dans la progression pédagogique est « avant d’aborder les suites ». Voici le début de l’énoncé proposé aux élèves :

Je ne m’attarderai pas sur la version classique de l’algorithme, illustrée ici pour le nombre 49 avec 7 itérations :

Voici le résultat obtenu en version dynamique pour le même exemple, avec une échelle de 5 pour n en abscisse :

Pour faciliter la lecture du programme correspondant, une fonction intermédiaire calculant la somme des carrés des chiffres d’un entier x quelconque est introduite :

La programmation à réaliser ensuite ressemble à celle effectuée pour l’exemple précédent (suite récurrente), où le graphique dynamique est obtenu en construisant une liste de points :

E) Calcul infinitésimal

Intégrale : méthode des rectangles

Cet exemple a été traité en partie dans la section B. Il reste à expliquer comment a été obtenue la courbe de la primitive (en bleu) ainsi que les deux traits verticaux délimitant l’aire :

Voici le code complet, hormis celui des fonctions « f » et « integrale » :

On peut noter que les deux courbes ont une qualité de représentation très différente, alors qu’elles sont définies par deux blocs similaires. Cela s’explique par l’interprétation qu’en fait SofusGeo :

  • quand les bornes de x ne sont pas précisées, SofusGeo utilise le grapheur de DGPad
  • quand les bornes de x sont précisées, SofusGeo construit et affiche une liste de 101 points (soit 100 segments) ; cette technique est nécessaire lorsque le grapheur ne sait comment traiter la fonction à représenter graphiquement, ce qui est le cas pour l’intégrale.

La procédure « delimiter » construit les deux segments verts verticaux. Dans l’absolu, il aurait été souhaitable de définir une procédure paramétrée par l’abscisse du trait, puis de l’appeler deux fois (une pour le curseur « a » et une pour le curseur « b »), mais je ne suis pas arrivé à combiner procédures paramétrées et curseurs dans SofusGeo.

Dérivation et tangente

Pour illustrer les notions de tangente et de dérivée, deux points sont introduits sur une courbe : l’un (A) est mobile, tandis que l’autre (B) dépend du premier et d’un curseur (h) fixant l’écart entre l’abscisse des deux points.

Donc, plus la valeur du curseur est proche de 0, plus la droite AB est proche de la tangente à la courbe en A. La pente de la droite est affichée dans une expression, comme le montre le programme ci-dessous :

Pour tracer la courbe de la dérivée, il suffit d’introduire un point (nommé « lieu ») dont l’abscisse est celle du point A et dont l’ordonnée est la pente :

Le déplacement du point A entraîne celui du point « lieu », qui laisse alors une trace orange :

F) Conclusion

Patrice Debrabant avait établi une liste beaucoup plus longue de problèmes d’analyse pouvant être traités en programmation dynamique. Je ne les ai pas intégrés dans l’article pour diverses raisons, la première étant qu’un article trop copieux risquait de devenir indigeste.

Seconde raison, j’aurais encore dû faire évoluer SofusGeo pour pouvoir traiter certains de ces exemples : or, je venais d’effectuer un gros travail de programmation, d’où un manque de motivation...

De plus, SofusGeo n’a pas pour utopique vocation de traiter tous les problèmes pouvant l’être avec DGPad, tellement la palette de ce logiciel est riche, mais de permettre à des élèves ou à des enseignants ne connaissant pas (ou peu) DGPad d’aborder simplement quelques problèmes usuels. Un des problèmes traités dans l’article met particulièrement en lumière la simplification qu’apporte SofusGeo : il suffit en effet d’un seul bloc pour représenter graphiquement la courbe de la primitive, alors qu’avec DGPad il faut créer une expression et lui associer un programme Blockly créant une liste de points. Par ailleurs, SofusGeo ne nécessite que des connaissances en programmation par blocs, alors qu’un apprentissage de l’environnement de DGPad est nécessaire car certaines tâches (création de curseurs, d’expressions, d’objets géométriques) s’y font sans programmation.

Annexe : patron d’un cône de révolution et extremum

Introduction

Il y avait dans le liste d’exemples de Patrice Debrabant un problème qui me plaisait beaucoup, mais impossible à traiter avec SofusGeo. Alors, pourquoi y consacrer une annexe ? En voici deux raisons :

  • l’envie de parler d’un problème attractif, y compris hors du cadre de la programmation dynamique.
  • l’envie d’évoquer la solution DGPad que m’a transmise Patrice, solution qui peut être testée en ligne grâce à un lien que je donnerai.

Résolution dynamique avec DGPad : les grandes lignes

La solution DGPad proposée par Patrice Debrabant peut être testée en ligne en cliquant sur ce lien. En voici une copie statique que je vais commenter :

On peut faire varier le secteur angulaire en déplaçant un des deux points sur le cercle rose, ce qui a deux conséquences : une modification du cône, ainsi que l’affichage de la courbe (grâce à un point laissant une trace, technique utilisée à plusieurs reprises dans l’article).

Cette solution DGPad résulte d’une savante alchimie entre manipulations (construction du secteur angulaire, création d’un repère 3D, création des axes du graphique sans le libellé...) et programmation par blocs (tracé du cône grâce à une tortue 3D, libellé des axes grâce à une tortue 2D).

Tracé du cône avec une tortue 3D : les détails

Pour accéder à l’environnement de programmation de la tortue 3D dessinant le cône, il faut procéder ainsi :

On obtient alors un programme par blocs plutôt abscons, que je vais tenter d’expliquer « simplement » :

Les deux premiers blocs du « répéter » dessinent un polygône régulier P1P2 ... Pn en tournant de 360/n degrés et en avançant de la circonférence de la base du cône (de rayon R*k) divisée par n. S’il ressemble à une ellipse (et pas à un cercle), c’est parce que le point associé à la tortue est un point 3D.

Le troisième bloc du « répéter » fait pivoter la tortue autour de l’axe PkPk+1 (l’axe X de son repère mobile), si bien qu’elle se retrouve dans le plan PkPk+1S.

Ensuite, la tortue se déplace dans ce plan comme n’importe quelle tortue 2D afin de dessiner le triangle, avant de retourner dans le plan horizontal pour la prochaine itération. Le quatrième bloc du « répéter » ( « gauche 90+A1/(2*n) » ) permet d’orienter la tortue vers le point S.


notes

[1Si ce menu s’appelle DGPad, c’est parce que SofusGeo s’appuie sur ce logiciel de géométrie dynamique pour exécuter les programmes : les blocs de SofusGeo sont traduits en Javascript, le code Javascript étant ensuite envoyé au serveur de DGPad. SofusGeo s’adresse prioritairement à des enseignants ou des élèves ne connaissant pas (ou peu) DGPad.

[2Petite digression qui intéressera certainement les enseignants de lycée dans le contexte actuel, il est possible d’obtenir automatiquement la traduction de ce programme visuel SofusGeo en Python. Pour cela il suffit en effet de sauvegarder ce programme par blocs (bouton « Sauver »), puis de passer au logiciel SofusPy : en effet, les blocs non géométriques de SofusGeo étant aussi gérés par SofusPy, on peut récupérer ce fichier dans SofusPy pour le traduire en Python.

[3Un moyen de fournir le programme aux élèves est que le professeur le réalise lui-même avant le TP, puis l’enregistre : il ne reste plus qu’à le transmettre aux élèves pour qu’ils l’ouvrent avec SofusGeo.

[4Et si au lieu de l’aire du quadrilatère on avait voulu afficher le périmètre, la valeur de l’expression aurait été la suivante : « d(O,A) + d(A,B) + d(B,C) + d(C,O) ».

Documents associés à l'article
     |   (Texte - 28.4 ko)
Réagir à cet article
Vous souhaitez compléter cet article pour un numéro futur, réagir à son contenu, demander des précisions à l'auteur ou au comité de rédaction...
À lire aussi ici
MathémaTICE est un projet
en collaboration avec
Suivre la vie du site Flux RSS 2.0  |  Espace de rédaction  |  Nous contacter  |  Site réalisé avec: SPIP  |  N° ISSN 2109-9197