Les nouvelles technologies pour l’enseignement des mathématiques
Intégration des TICE dans l’enseignement des mathématiques

MathémaTICE, première revue en ligne destinée à promouvoir les TICE à travers l’enseignement des mathématiques.

Programmation Visuelle Dynamique (PVD) - Le cas de DGPad

La programmation visuelle a, en général, un support et une sortie statiques. On explore ici le cas de DGPad, où la programmation visuelle est inscrite dans un environnement dynamique.

Article mis en ligne le 10 mai 2016
dernière modification le 23 octobre 2021

par Yves Martin

La programmation visuelle a un support et une sortie statiques. Le logiciel de géométrie dynamique DGPad vient d’intégrer la programmation visuelle (PV), avec une interface Blockly. Cet article se propose d’explorer en quoi une interface d’un logiciel de GD peut dynamiser la programmation visuelle. Nous allons le faire dans un situation générique des blocs « de comportement », ce qui n’est qu’une première partie des possibilités de cette programmation. Nous allons voir qu’elle est en elle-même déjà très riche. Un autre article abordera ultérieurement une autre partie de cette intégration de la PV à la géométrie dynamique.

Cet article peut être librement diffusé et son contenu réutilisé pour une utilisation non commerciale (contacter l’auteur pour une utilisation commerciale) suivant la licence CC-by-nc-sa

Note additionnelle
L’article a été mis en ligne le 10 mai. A la fin il parle de l’arrivée imminente de la tortue DGPad.

Depuis la tortue dynamique de DGPad est arrivée. Un long article lui a été consacré en novembre 2016. On notera les possibilités d’algébrisation de la tortue de DGPad par exemple et ses possibilités 3D.

Un an après la rédaction de cet article, un iBook résumant ces deux articles (et un peu celui sur les spirolatères) est disponible - il est gratuit - en téléchargement à cette adresse :

http://itunes.apple.com/fr/book/id1231386212

Sur iTunes car c’est un iBook, donc un format particulierement riche (i contient 82 figures DGPad) mais lisible seulement sous Mac OS ou iOS (iPad). Désolé pour Android et autres.

Mais si vous avez un iPad ou un Mac dans votre environnement proche, cela mérite d’être vu : ce n’est pas souvent que l’on programme dans un livre, et qui plus est de manière dynamique.

Les 4 derniers chapitres reprennent une partie de cet article, en particulier la partie récursive et la partie sur le déterminisme. Le reste est sur la tortue Blockly de DGPad. Ce livre fait 186 pages.

La programmation visuelle (PV) fait son entrée institutionnelle, curriculaire, en mathématiques au collège à la rentrée 2016 (et plus généralement à partir du CE1-CE2). Elle est souvent déjà pratiquée au collège, y compris en mathématique, soit à l’occasion, par les collègues, pour se préparer aux nouveaux programmes, soit même dans des organisations spécifiques si on veut installer une pratique régulière (comme les heures numériques à Grenoble dès 2014, parmi d’autres initiatives, et, surtout, plus régulièrement en technologie (pilotage de robots ou de cartes) car déjà dans les programmes, avec des ressources Eduscol disponibles (et la version Scratch GPIO pour piloter le Rapsberry Pi). Toujours au collège, on trouve aussi des instrumentalisations de Scratch originales, plus surprenantes comme dans ce site de SVT qui utilise Scratch pour des QCM originaux de ce type (ici copie d’écran) :

L’arrivée de la PV a aussi largement investi les colonnes de MathémaTICE, avec de nombreux articles dans ses derniers numéros, sur Scratch ou Snap, dont l’extraordinaire article de Jean Philippe Varoyen de ce numéro, Studio.Code ainsi que Blockly, ici (Alain Busser) ou (Patrick Raffinat) dont le Sofus de Alain et ses tortues, dans ce même numéro. Et si on ajoute la programmation pour le collège, même si elle n’est pas « visuelle » (au sens ordinaire du terme,) il y a également également GeoTortue, très efficace logiciel utilisable à l’oral du CAPES avec l’article de Julien Pavageau.

De la PV à la PVD - un premier pas

Cet article se propose de présenter un nouvel outil, construit autour d’une extension spécifique de Blockly.

« - Un nouvel outil ? Après tous ceux que tu viens juste de citer ? Pourquoi s’intéresserait-on à un nouvel outil, avec la panoplie de ce qui est déjà disponible ? »

« - Pour le D, pour la dimension dynamique. Parce que les concepts évoluent, faisant se rencontrer la programmation visuelle et la géométrie dynamique, Eric Hakenholz a créé un nouvel outil, voire un nouveau concept, la programmation visuelle dynamique, (PVD) et dans laquelle il est très facile de rentrer si on a déjà fait de la PV. »

Un premier pas

On aborde ici un premier pas vers la PVD. En effet, dans la programmation visuelle, on peut distinguer deux champs : ce qui se passe sur la scène en général, et les échanges entre lutins. Même si cet échange entre lutins a bien entendu une incidence directe sur la scène, ce sont deux niveaux d’interaction différents en terme de programmation. Clairement, en sixième par exemple, il y a de quoi apprendre sur la scène avec un seul lutin, et d’ailleurs le programme invite à commencer l’échange entre lutins à partir de la classe de 5°. J’ai pu observer des élèves (à une troisième séance Scratch, dans un environnement d’utilisation très satisfaisant) qui, croyant avoir bien compris comment on faisait faire un carré au lutin, ont été assez décontenancés quand leur enseignante leur a demandé de passer à un rectangle, simplement numérique, bien entendu, avec une longueur et une largeur données.

Dans la version PVD il y a aussi cette distinction, et bien entendu cette interaction entre les deux. Plus précisément, il y a un Blockly de Scène, qui agit sur l’ensemble de la figure. Cela correspond aux CarScripts de CaRMetal, comme les très belles programmations de Patrice Debrabant dans l’article sur les tortues, de ce même numéro. Cela s’appelle d’ailleurs un DGScript comme dans cette palette de création :

un exemple de DGScript sur la simulation de la somme d’un lancer de deux dés (figure analysée dans l’onglet Blocs d’actions dans la 3° barre d’onglets).

Puis il y a un Blockly de comportement qui correspond plus à l’échange entre lutins, c’est-à-dire entre les objets déjà crées sur la figure. Il est dans la palette de comportement (3° icône depuis la droite sur cette palette de comportement de points).

Plus généralement, le Blockly de comportement va traiter des modifications des objets déjà créés (y compris dans leurs propres définitions), et le Blockly de Scène va aborder plutôt, la création des objets et la gestion générale de la figure. Il comporte par exemple une tortue « dynamique ».

Finalement, pour Eric Hakenholz, ce que l’on fait actuellement au collège, en Scratch ou en Snap, correspond plutôt au Blockly de scène (dans un usage standard). Mais ce n’est pas de cela que ce premier article sur la PVD va parler, il va traiter de l’autre aspect de la programmation visuelle, l’aspect d’interaction, on dira ici de comportement des objets. Cela comprend des choses assez différentes, comme la définition des objets, en interaction bien entendu avec ceux déjà sur scène ou des définitions multi-référentes entre objets . On va voir en effet, que, dans le cas de la PVD, la dimension d’échange entre les lutins prend une nouvelle dimension, pas toujours si nouvelle, certaines fonctionnalités sont déjà disponibles dans CaRMetal ou parfois dans Geogebra, mais sous des formes plus techniques, ou plus hermétiques de par les syntaxes spécifiques. Ici c’est de la programmation visuelle tout simplement.

Traitant de la programmation de comportement des objets, on comprendra que, dans ce premier article, on ne va pas mettre en œuvre des scripts utilisables en collège, pas du tout (mais pour le lycée, c’est possible). Il s’agit plutôt de se familiariser avec des outils de programmation visuelle placés dans un contexte dynamique. Les utilisations peuvent être géométriques ou non. Pour ma part je l’utilise déjà dans mes cours, en particulier de L1 Biologie pour construire toutes sortes de figures sur les systèmes dynamiques de populations. Les systèmes différentiels associés étant non intégrables, il s’agit d’approcher leurs trajectoires (2D) et leurs solutions (courbes intégrales en 3D). Pour cela, le Blockly de DGPAd fait merveille.

C’est l’occasion de préciser une autre conséquence de l’intégration de Blockly dans DGPad. Le logiciel, disponible en WebApp sur ordinateur, a surtout été construit pour être utilisé sur tablette. L’interface tactile ne permet pas d’avoir accès à toutes sortes de possibilités de réglages et en particulier n’avait, pour ses réglages d’objets, que des possibilités numériques - ce qui bien entendu est généralement suffisant pour une utilisation scolaire classique, mais limité pour une utilisation plus « professionnelle ». L’intégration de Blockly a permis de rendre algébriques de nombreux paramètres d’aspects de DGPad. Nous en donnerons quelques illustrations. Par ailleurs, pour une utilisation plus efficace dans les systèmes dynamiques, l’auteur du logiciel a bien voulu créer un premier aspect qui n’est disponible que dans Blockly : l’aspect flèche de vecteur disponible pour les listes de segments, ce qui permet de construire de beaux champs de vecteurs, très fluides, puisqu’ils ne compte que pour un seul objet (alors qu’en interne ils peuvent en contenir entre 800 et 1200). Qu’il en soit ici remercié vu que c’était une demande assez personnelle, pour mon cours de maths en biologie.

Pourquoi ne pas traiter aussi du Blockly de scène ? Simplement parce que au moment de la rédaction de cet article, il n’est pas totalement opérationnel, en terme de créations. Eric Hakenholz a en effet choisi de développer le plus difficile : si cette partie d’interaction entre les objets n’avait pas pu être possible, et avec toute la richesse qui va être présentée ici, la seconde, bien plus simple à mettre en œuvre, n’aurait été finalement que de moindre d’intérêt. Il a donc travaillé plus avant cette partie, que, avec Monique Gironce, ancienne auteure de MathémaTICE, nous avons alpha, puis beta-testé avant qu’elle puisse désormais être présentée.

Organisation de l’article

L’article est structuré en 4 parties, dans 4 barres d’onglets vers lesquelles on peut aller directement.

La première partie revient sur la programmation visuelle. Elle propose une réflexion sur son interface et aborde surtout les aspects dynamiques naturellement possibles en PV standard en rendant hommage au travail d’Alain Busser et de Florian Tobé sur la question ; travail précurseur qui a permis ensuite à Florian, dans le projet multi-tortue de Sofus, d’aller au delà des limites de Scratch en terme de clonage d’objets.

La deuxième partie fait un point sur le minimum de ce qu’il faut savoir de DGPad pour finaliser partiellement les figures proposées ou, simplement les manipuler en toute aisance.

La troisième partie est le cœur de l’article. On y présente les différentes possibilités de la PVD, en tant qu’outil de comportement des objets existants. Les quatre premiers onglets présentent les possibilités opérationnels de la nouvelle interface de blocs, alors que les trois derniers onglets abordent, certes toujours de manière constructive, des aspects plus théoriques sur ce que permet l’interfaçage de Blockly avec la Géométrie dynamique.

La dernière partie triate d’un sujet spécifique, la récursivité. En effet, Blockly se comporte assez mal avec la récursivité. Eric a dû réécrire une partie pour que les matheux retrouvent leurs petits ... Là aussi, clairement ce n’est pas du niveau du collège, même si on va (re)faire une jolie fractale de Pythagore.

Vous êtes donc invités à poursuivre soit en lecteur, soit en manipulant sur quelques figures simples à réaliser qui seront largement détaillées dans des blocs de réalisation.

La première prise en main détaillée de Blockly dans DGPad est dans le dernier onglet de la première barre d’onglets.

1. Généralités sur la programmation visuelle.
2. Philosophie de DGPad – Prise en main rapide.
3. Les aspects dynamiques de la PVD.
4. La récursivité dans le Blokly de DGPad.

Toutes les figures proposées sont téléchargeables en fin d’article.


1. Généralités sur la programmation visuelle

Manipulation directe

La programmation visuelle est en manipulation directe

Le terme de programmation visuelle signifie qu’elle donne à voir les objets ou les structures, comme les boucles de répétition, au lieu de les écrire : on met régulièrement en avant que d’une part on résout les questions de syntaxe, mais aussi que les élèves ont à choisir l’outil dans un panel qu’ils ont sous les yeux.

Le point de vue d’une pratique de la géométrie dynamique (GD) fait émerger une autre évidence : la programmation visuelle est surtout en manipulation directe. On prend un objet et on le met en oeuvre, que ce soit dans le corps du script (en général, surtout dans les petites classes) mais aussi dans une boucle ou une instruction conditionnelle par exemple. De ce point de vue déjà, la programmation visuelle et la géométrie dynamique partagent des comportements communs essentiels ...

Des comportements communs ... mais aussi d’importantes différences : la programmation visuelle (PV), si elle est en manipulation directe pour ses briques élémentaires, a un environnement de sortie statique (sauf expertise que l’on traitera plus loin). On est donc particulièrement intéressé de voir ce que peut donner une PV quand elle va être « dynamisée » par l’environnement dans laquelle elle va s’inscrire.

Par ailleurs, toujours d’un point de vue d’une géométrie dynamique qui a réalisé à la fois l’anticipation des constructions, y compris sur tablette, mais aussi la mise à jour en temps réel de ses actions diverses, comme c’est le cas de DGPad, cela signifie que la PV dans un environnement dynamique se doit de respecter le principe d’anticipation de la construction et du temps réel. Nous verrons que c’est le cas, y compris dans des situations extrêmes (en fait il n’y a pas de situation extrême).

Une manipulation directe pour quoi faire ?

De nombreuses études didactiques, en particulier sur l’utilisation du logiciel historique CABRI Géomètre, mais aussi plus récemment dans la thèse de Francine Athias utilisant TraceEnPoche, ont montré que la manipulation directe, dans cet environnement de géométrie dynamique, est potentiellement conceptualisante chez les élèves, en ce qui concerne les propriétés géométriques. Pour autant cette capacité de conceptualisation ne va pas de soi. Elle relève de plusieurs facteurs, comme la qualité de l’interface du logiciel - son ergonomie, son anticipation des constructions, plus généralement de tout ce qui relève d’un regard a-didactique dans la conception du logiciel - mais aussi du type d’activités proposées aux élèves.

Fondamentalement, c’est la mise en oeuvre de la géométrie dynamique, dans des activités, qui la rend conceptualisante ou non. Cette expérience de plus de 25 ans de géométrie dynamique peut être mise au service de l’introduction de la PV. Dans quelle mesure sa pratique régulière, de la 6° à la 3°, peut-elle être conceptualisante, et dans quels domaines ?

La question est débattue, déjà dans les instances de formation, mais pas seulement bien entendu. La pratique de Scratch, par exemple, est-elle une transposition didactique - ou peut-elle accompagner une transposition didactique - de l’apprentissage de la Programmation Orientée Objet (POO) ? Est-ce seulement l’objectif de cette mise en avant de la PV ?

Rien n’est moins sûr. En effet quand on s’intéressait à l’impact de la GD sur les apprentissages, nous étions encore dans un monde où l’on se proposait de transmettre des savoirs. Nous sommes désormais dans un environnement éducatif où le savoir n’est plus le centre d’intérêt principal (on le pense alors comme « naturellement diffus ») mais où les compétences ont pris la relève.

L’arrivée d’une nouvelle science au collège (car dans ISN - même si le sigle n’est pas au collège - le S signifie Science) ne cherche pas à cibler une transposition didactique des savoirs savants de celle-ci, mais plutôt des compétences d’opérationnalité effective sur une pratique (réaliser un pong, un labyrinthe, un jeu de bataille navale). Cette nouvelle science construit effectivement et illustre magistralement la migration du système éducatif du champ du savoir vers celui des compétences.

Alors, la manipulation directe de la PV pour quoi faire ? Pour participer à l’évacuation du savoir et l’installation des compétences ? Vision bien trop machiavélique et caricaturale. Pour installer une certaine bienveillance - pas toujours acquise chez les collègues - en « acte » vis à vis de l’évaluation par compétences ? Probablement, et pourquoi pas ?

Et cela fonctionne ! En tout cas avec les jeunes générations. Ce qui est frappant, dans la pratique actuelle de Scratch en classe chez les stagiaires M2 MEEF, futurs titulaires, (puisque c’est mon domaine d’investigation privilégié), c’est la sensation de liberté expérimentale laissée aux élèves pendant les séances Scratch : les élèves essaient un programme, se trompent, réfléchissent, corrigent et recommencent (l’algorithme étant « jusqu’à ... »). J’ai pu observer la même attitude au lycée, en seconde, avec Tickle. Les jeunes stagiaires sentent - et parfois même en sont heureux - qu’ils peuvent pratiquer efficacement ce qui leur est enseigné dans leur formation, la mise en valeur de l’erreur, si chère au constructivisme : les élèves apprennent effectivement directement de leurs propres erreurs, et dans un environnement sophistiqué comme la PV, avec le feedback d’un RunTime immédiat (drapeau vert ou autres), l’apprentissage sur ses erreurs est auto-référent, sans intermédiaire. On est d’ailleurs plutôt dans un contexte de socio-constructivisme, car en général les élèves sont par binômes et apprennent plus vite de leurs erreurs par concertation.

Différence entre géométrie dynamique et programmation visuelle

Quand je précise que les stagiaires M2 en sont parfois heureux, cela exprime la satisfaction de mener de telles activités, en cohérence avec ce qui est demandé par l’institution, mais aussi, parfois, un certain soulagement que cette expérimentation soit finalement confinée à une pratique spécifique bien ciblée, vécue comme « sans risque » : sous Scratch, les élèves « peuvent expérimenter » et « vont finir par trouver ». Comme si cette démarche n’était pas possible « en maths », ailleurs qu’en programmation. Pourtant, en géométrie dynamique, quand on réalise une construction géométrique élémentaire, c’est-à-dire un programme de construction, on fait - conceptuellement et cognitivement - la même chose. Déplacer les points de base est une expérimentation au même titre que cliquer sur le drapeau vert, et la confirmation que le programme de construction de la figure est correct se fait avec le même feed-back : la confirmation, de fait, est visuelle et cognitive, que le carré ou le rectangle à construire soit sous GeoGebra ou sous Scratch. Et pourtant, pour tout le monde, les élèves comme les enseignants (ceux en formation initiale du moins), les deux activités sont perçues différemment. Alors quelle différence ? Dans un cas, on est « en géométrie », les icônes et fonctionnalités du logiciel le rappellent, dans l’autre on est « en informatique » (mêmes raisons), et pourtant les commandes relèvent dans les deux cas des propriétés des figures, et ces propriétés ne sont que des outils mis en oeuvre.

Mais fondamentalement, dans le premier cas, le programme de construction agissant sur des droites et des points, on travaille du côté du savoir, plus précisément les élèves impliquent leurs propres rapports au savoir mathématique dans la construction effectuée. Dans l’autre cas - pour les première utilisations de collège - donnant des instructions d’action à un lutin, il y a un transfert. Une dépersonnalisation de l’action s’installe et, à travers elle, le rapport au savoir (et à la culpabilité de l’erreur) s’évanouit : l’élève est tout absorbé à la tâche de faire faire au lutin ce qu’il souhaite qu’il fasse. Il s’agit donc de donner les bonnes instructions. Le rapport au savoir peut être évoqué par l’enseignant, mais il est nettement plus anecdotique pour l’élève, que dans la même activités avec un logiciel de géométrie dynamique où il est, de fait, le seul référent pour la démarche. On pourrait faire l’analyse que cela fonctionne ainsi, en PV, car on est dans une sorte de dévolution ultime de la tâche. C’est possible. Mais dire cela suppose que l’on se place encore dans un registre référant au savoir. Cela dépend vraiment de la façon de mener l’activité par l’enseignant, de son véritable objectif. Pour ce que j’ai pu observer en classe, il n’est pas certain que l’enseignant soit effectivement dans ce registre là : la dévolution du lutin, puisque c’est bien de cela dont il s’agit, fait basculer l’ensemble des acteurs de la salle informatique (pour des raisons différentes) d’un monde du savoir vers un monde de compétences. De l’ancien monde, connu pour ses valeurs bien identifiées (théorie, savoir), vers un nouveau monde en construction, avec ses valeurs (exploration, créativité, vitesse) connues mais encore à préciser, en particulier dans les curricula (sujet encore ouvert), celui que construit par exemple l’école 42 partiellement transposé ainsi, quelques heures par mois bien entendu, dans les collèges.

Un peu de prospective à peine futuriste

Sur la base de ce passage, jugé nécessaire par la société en général, de savoirs anciens vers des compétences contemporaines - la question n’est pas franco-française, l’invitation « à coder » vient des plus importants responsables de la planète - le tour de force, et le génie peut-être, des lobbyistes est d’avoir réussi à installer cette transformation, profonde, dans la matière qui était encore ces dernières années pour la société, la matière dite « de sélection » pour que, à terme, la sélection se métamorphose de manière interne au système, avec un minimum de visibilité externe, comme le souhaitent finalement les lobbyistes : on va simplement transformer un des champs disciplinaires par l’approche curriculaire, par petites touches, sur plusieurs années, et en même temps modifier le recrutement des enseignants de ce champ disciplinaire : bientôt des personnes qui n’auront quasiment plus fait de mathématiques depuis la terminale vont avoir le CAPES de mathématiques et enseigner pendant 42 ans ! On peut penser qu’elles ne vont pas enseigner longtemps (que) les mathématiques, une phase 2 sera mise en place bien avant.. Chapeau bas Mr Gilles !

Les astronomes assistent « en direct » à l’explosion de supernovae qui ont pu avoir lieu il y a des millions d’années. Sur terre, nous assistons en temps réel (et c’est une valeur contemporaine ;-) à d’autres explosions auxquelles nous participons nous-mêmes par notre propre enthousiasme, en nous disant que ce ne sont pas des explosions, mais plutôt des mutations, avec cette idée que l’on peut les accompagner pour que certaines valeurs de l’ancien monde - la conceptualisation par exemple - ne soient pas trop rapidement rayées des registres.

Pour un maintien d’une démarche conceptualisante

Bien entendu l’analyse précédente sur les premières séances Scratch de quelques étudiants-stagiaires n’est que locale, même si elle pose des questions fondamentales. Elle est aussi locale aux premières années de la nouvelle réforme, mais aussi aux premières années du collège. Une fois que tout le monde aura fait de la PV depuis plusieurs années (depuis le CE2), « la dévolution du lutin » n’aura probablement pas la même intensité, les attitudes de chacun seront alors à replacer en perspective.

Une conséquence immédiate de cette analyse nous intéresse directement. En effet, a priori, il semble que la PV installée au sein d’un logiciel de géométrie dynamique risque de ne pas avoir la même dimension dévolutive qu’un lutin. C’est une question ouverte, qui sera à explorer en classe, car la dimension dynamique du support peut faire migrer la dévolution vers d’autres pratiques et d’autres réflexions.

On aura compris que cet article, centré sur la formation continue des enseignants, milite pour le maintien d’une démarche conceptualisante. À cette fin, même si les activités proposées n’iront pas toutes dans ce sens, cette démarche reste le fil rouge de cet article, on le verra dans les deux dernières parties.


Haut de la barre d’analyse de la PV (pour onglet suivant)
Barre suivante : Prise en main rapide de DGPad

Interfaces

Sur les interfaces

La diversité des applications de programmation visuelle permet une première réflexion sur les interfaces.

Les blocs de mathématiques

Même si la PV n’a pas été conçue pour cela, une instrumentalisation mathématique - un peu comme celle en SVT ci-dessus - pourrait être l’utilisation des blocs mathématiques pour un changement de cadre (dynamique, avec manipulation des blocs) pour l’apprentissage de certaines règles de priorité en arithmétique ou en algèbre. On imagine bien des activités de renforcement ou de remédiation sur les règles de priorité et le parenthésage où il s’agirait de déplacer des blocs déjà remplis pour obtenir des résultats numériques ou algébriques proposés. Le changement de cadre réside alors dans l’imbrication des blocs à la place, ou comme autre symbolique du parenthèsage. Pour cela il faut une visibilité claire sur les blocs imbriqués.

Voici trois interfaces. On reconnaitra, à gauche, Scratch, à droite, Snap, et en dessous Blockly.

On voit bien que, dans sa version 2 actuelle, l’imbrication des blocs de Scratch n’est pas assez visible pour de telles activités. Celle de Snap est nettement plus claire. La version de Blockly est plus massive, mais nettement plus utilisable pour ce type d’activité. De plus le contour surligné peut être l’opportunité d’instrumentalisation mathématique.

A priori, Scratch va rapidement arriver sur tablette et devrait proposer une interface plus sophistiquée (on peut le souhaiter en tout cas). Cette analyse est donc peut-être provisoire.

La modification des constantes numériques

Dans Scratch, comme on travaille sur ordinateur, il n’y a pas de problème sur le sujet. La question de l’accessibilité aux nombres se pose sur tablette : faut-il que le clavier standard apparaisse à chaque instant quand l’utilisateur veut modifier une constante de son programme ? C’est clairement non ergonomique.

L’application Tickle (gratuite, mais pour le moment seulement disponible sur iOS) a résolu la question de manière très élégante. Un petit clavier numérique pour les nombres, et une roue pour les angles apparaît dés que l’on veut modifier une constante.

La manipulation des variables

Toujours sous Tickle, un bouton permet de créer des variables, elles sont ensuite manipulables au doigt. Néanmoins, une difficulté - en tout cas un problème - apparaît à l’usage dans l’interface de Tickle. En effet, pour nommer la variable sur tablette, il est naturel que le clavier standard apparaisse.

Ceci étant acquis et nécessairement pratiqué par les élèves, la situation se complique avec, au moins, les tests booléens. Dans l’illustration suivante, nous sommes dans une classe de seconde qui a utilisé l’application Tickle déjà deux fois (et la tablette par binôme une fois par semaine depuis plusieurs mois). On voit en haut de l’écran qu’il s’agit de piloter un robot Ollie (de Sphero). Il y avait trois types de robots dans cette séance en groupe : deux Sphero, deux Ollie et un BB-8 soit 5 robots pour 16 élèves. Une variable A a été créée par le groupe d’élève. Les commandes sur les variables sont en orange (on le voit à gauche et dans le script). Puis la variable A apparaît dans un test booléen vert (dans une boucle « répéter jusqu’à »). On ne s’intéresse pas ici aux incohérences du programme.

Compte tenu de ce que l’on peut mettre dans les tests conditionnels - par exemple pour tester les caractères avec des exercices de cryptographie - pour entrer des données dans le test vert, ce n’est plus un pavé numérique qui apparaît comme ci-dessus, mais le clavier standard, y compris pour entrer le paramètre 3. Tout naturellement (même s’il est « naturel » pour un enseignant de ne pas faire cela), plusieurs élèves ont aussi rentré le nom de la variable dans l’autre prémisse du test vert, d’où le A sur fond vert foncé dans l’illustration ci-dessus, alors que si les élèves avaient pris la variable A elle aurait été sur fond orange. Et bien entendu, indépendamment des incohérences propres au script, ce A là, tapé au clavier virtuel, n’est pas la variable A créée en interne juste avant. Avec le stagiaire en responsabilité dans la classe, il nous a fallu un peu de temps pour détecter l’erreur de manipulation.

On voit donc qu’il faut être prudent parfois sur certaines interfaces qui peuvent être informatiquement cohérentes et didactiquement sources de confusions.

Dans Blockly, ce type de mésaventure ne peut pas apparaître, car outre la création interne de tous les objets sous forme de blocs, il y a en plus un contrôle de type, ce qui fait qu’on ne peut incorporer un bloc comme prémisse d’un autre si son type n’est pas compatible avec ce qui est attendu.

Bien entendu le programmeur de l’extension Blockly qu’il va intégrer à son application peut aussi faire ce qu’il veut. Pour faire gagner du temps aux enseignants par exemple, il y a la tentation de créer un bloc d’expression dans laquelle l’enseignant pourrait directement entrer une expression trop longue à installer dans le moule blockly, comme celle-ci :

Mais l’exemple de Tickle montre les dangers qu’il peut y avoir, dans le cadre d’une utilisation par les élèves, d’un tel outil pourtant facile à concevoir. Actuellement un tel bloc ouvert à l’écriture mathématique standard, comme dans un langage de programmation, n’a pas été réalisé, et donc, même pour des systèmes dynamiques complexes, on passe par le formatage de Blockly comme ci-dessus (mais ce n’est pas une activité scolaire, bien entendu).


Haut de la barre d’analyse de la PV (pour onglet suivant)
Barre suivante : Prise en main rapide de DGPad

Aspects dynamiques

Onglet rédigé sous forme de narration, car c’est trop joli ...

Les apports dynamiques de Florian Tobé et Alain Busser

Genèse de cet onglet

Dans mes formations initiales, je fais construire « le cœur de Tournesol » selon une formule de Vogel, issue de cet ouvrage de d’Aristide Lindenmayer (les L-systèmes) à la page 112 du PDF.

Avec l’angle de 137,5°, soit une approximation de $\frac{2\pi}{1+\Phi}$ où $\Phi$ est le nombre d’or, le nombre de spirales dans les deux sens sont deux nombres consécutifs de Fibonacci.

Je fais faire cela en ajoutant un curseur à la place de l’angle fixe pour avoir une figure dynamique intéressante, que l’on fait en M1 au tableur, en M2 sous forme de liste de Geogebra (GGB) ou de listes de DGPad (avant l’arrivée de Blockly). L’intérêt de DGPad est que le même objet liste peut être aussi bien avec des points que des segments, la différence n’est qu’un aspect de l’objet liste.


(à gauche, avec des points, à droite, la même liste, avec le même angle, sous forme de segments)

Un autre intérêt de DGPad pour ce genre de situation est dans le fait que les points et les segments sont virtuels, ils ne sont pas créés comme dans les séquences de GGB. Le fichier est donc très petit, et la manipulation de la figure très fluide. Examinons, exceptionnellement, le code produit (donc avant Blockly)

Le programme est dans l’expression E1 (ligne 9), il créée 500 points. La liste dessinée est en ligne 10. On voit qu’il n’y a ni 500 points ni 500 segments de construits. L’aspect de la liste est en ligne 18, p à 0 signifie que les points ne sont pas dessinés et sg à 0.3 indique l’épaisseur des segments pour la représentation graphique.

Quand la PV devient dynamique

Au cours d’une séance où nous devions travailler sur Scratch et quelques activités des articles MathémaTICE d’Alain Busser sur Blockly, je prononce cette phrase imprudente... : "Vous voyez qu’avec Scratch, la sortie est statique, on ne pourrait pas faire par exemple le tournesol que l’on a fait la semaine passée."

C’est alors que Florian (déjà bien connu localement comme animateur IREM et aussi étudiant cette année en M2) me dit tout de go :"Donnez moi 1/2 h je vous fait une POC que c’est possibe". Florian ne s’est même pas aperçu que les autres étudiants ont continué sur Blockly tout affairé à sa "proof of concept" et en environ 30 minutes, il a produit une parabole de la forme $f(x)=ax^2$ avec 50 points dont on pouvait modifier le paramètre $a$ en glissant la souris à l’écran.

Ce code, s’il n’est pas au programme de collège (les clones ont disparus entre la version de travail et la version définitive) et pas encore au programme de lycée, peut être travaillé en formation continue des enseignants, au moins à titre culturel.

La version en ligne : https://scratch.mit.edu/projects/95614318/

Le soir même, je recevais un version du tournesol dynamique sous Scratch du plus bel effet (maintenir le bouton enfoncé sans le déplacer).

La version en ligne : https://scratch.mit.edu/projects/95696333/
A noter qu’il faut lire le fichier en ligne, en local, le bouton ne réagit pas de la même façon car il est manipulable à la souris comme objet à éditer. Sur l’utilisation des clones, il y a une différence entre l’utilisation en ligne et dans l’application localement.
Le code est moins simple bien entendu, il y a un peu de programmation, y compris entre les lutins.

J’ai détaillé cette introduction au dynamisme dans Scratch car cela a été une révélation pour moi. En fait je n’avais pas compris que les clones pouvaient être utilisés (instrumentalisés) de cette façon. J’avais une représentation mentale trop limitée de Scratch.

Une POC du principe de géométrie dynamique sous Scratch

Suite à cette brèche ouverte, Alain Busser a alors montré que l’on pouvait dynamiquement créer le milieu de deux points, et plus généralement, Florian a créé l’isobarycentre dynamique de n points déplaçables à la souris.

L’ensemble de ces fichiers, et quelques autres, sont dans ce studio.

Bien entendu cette POC ne restera qu’une POC, on ne va pas traiter de l’intersection dynamique de deux droites (même si cela peut être fait bien entendu, ce n’est pas compliqué) et il n’est pas question de créer des cercles et des intersections de cercles, même s’il suffit de dire « qu’il n’est pas question de » pour que quelqu’un se penche sur la question ....

Haut de la barre d’analyse de la PV (pour onglet suivant)
Barre suivante : Prise en main rapide de DGPad

Les tortues de Sofus

Quand les sorties statiques peuvent être de toute beauté

Ces différentes POC du dynamisme dans Scratch a d’abord montré les limites de l’exercice. En particulier on ne peut construire que 300 clones dans Scratch. Ensuite elles ont surtout incité Florian à aller plus loin dans un véritable projet, et c’est ainsi qu’il a installé les multi-tortues dans Sofus, logiciel de programmation d’Alain Busser destiné au collège.

Comme illustration de l’utilisation du mode multi-tortues de Sofus, Alain Busser propose la version Sofus du DGScript sur le lancer de deux dés donné en lien en début d’article : le changement de point de point de vue est particulièrement intéressant puisque chaque tortue pilote un type de résultat du lancer (Avec la tortue Somme)

Mais cet onglet est ici pour illustrer que l’on peut faire aussi de très belles choses avec les tortues, même dans une sortie statique. Pour vous inviter à lire l’article d’Alain Busser et de Patrice Debrabant de ce numéro, quelques illustrations en sofus 1.4 (téléchargeable sur la page)

Et avec 4 tortues, cette superbe courbe de poursuite

Haut de la barre d’analyse de la PV (pour onglet suivant)
Barre suivante : Prise en main rapide de DGPad

de la PV à la PVD

Un premier exemple de Blockly sous DGPad guidé pas à pas

Il est temps de faire la jonction entre la PV et le D de DGPad, en attendant que ce soit plus généralement celui du Dynamique de la Géométrie Dynamique.

Introduction

On ne travaille dans cet article que sur des blocs de comportement, et ceci seulement sur des points et des listes (car pendant longtemps c’étaient les seuls objets disponibles dans Blockly) donc sur des objets déjà existant, dont on va modifier le comportement (pour les points) ou la définition (pour les listes). Bien entendu ces objets sont dynamiquement en interaction avec le reste de la figure.

Pour cette première présentation, je vous propose de reproduire une figure d’introduction que Eric Hakenholz propose dans ses présentations ou formations : il s’agit de construire les 500 premières puissances k-ièmes de l’une quelconque des racines n_ièmes d’un point (pour n allant de 1 à 500). On l’a dit, on ne va pas tout de suite faire du collège ou du lycée, l’objectif ici est de montrer à la fois la simplicité de la prise en main et la puissance du résultat.

1. Ouverture de l’extension Blockly

Le lecteur curieux est invité à faire lui-même la manipulation sur une figure déjà préparée. On a ici les copies d’écran de la marche à suivre. Pour cela commencer par ouvrir cette figure https://huit.re/BLK01a dans un navigateur au moins dans un autre onglet ou une autre fenêtre, de préférence sous Chrome, Firefox ou Safari. La figure ressemble à celle-ci (dans le navigateur il y a plus de place, ici on ressert la présentation pour être au format de la revue.

On va donc s’intéresser aux puissances d’une des racines n-èmes de P. Pour cela, on a déjà créé deux listes, la liste a va contenir les racines n-èmes, et la liste b les puissances de l’un de ces racines.Vous noterez le petit rectangle qui est simplement, par défaut, la représentation graphique de la liste b. En effet, mais c’est sans importance dans cette figure, a est une liste de points, b directement une liste de segments : c’est la même liste, seul l’aspect change : les points sont reliés, d’où la figure du rectangle.

Se placer en mode construction

Par défaut (en particulier pour un usage sur tablette) une figure en ligne est toujours en mode consultation : on ne peux pas créer des points par hasard en tapant sur la surface de l’écran. Pour construire quelque chose il faut sélectionner le mode construction, c’est-à-dire activer le pointeur de gauche dans le tableau de bord du bas : la flèche devient noire (active) au lieu d’être grise (inactive).

Sur la liste a, vous faite un clic (un tap long sur tablette) pour voir apparaître la palette de comportement et vous prenez l’icône de Blockly, celle de droite.

On entre alors dans l’interface Blockly (dans la figure en ligne, c’est plus grand)

L’interface Blockly est en transparence, on voit la figure dessous, et on voit les modifications en temps réel (si on a mis le retour) quand on en fait dans les blocs, nous en ferons un exemple plus loin.

Rien de bien particulier pour ce qui est de l’interface générale, la partie gauche contient les rubriques et les items Blockly, dans la partie du script les boutons de zoom (sur ordinateur la molette de la souris est un zoom, donc c’est un peu mieux que sous Snap car on peut s’adapter en fonction de la complexité du script ou la taille de l’écran). Le nom du script rappelle que l’on est dans la liste a.

Plus significatif, les deux onglets en bas de la feuille Blockly : expression (définition de la liste) et modifié (ce qui peut être fait si une liste est modifiée, typiquement par exemple une animation sur un curseur, mais pas uniquement).

Sauf cas exceptionnel, on sera toujours dans la définition : en effet, souvent c’est la définition d’une liste qui est modifiée par les curseurs (taille en temps réel etc), donc on travaille essentiellement dans cet onglet.

2. Réalisation d’une première instruction

Nous allons créer cette instruction à partir de la rubrique expression.

On voir bien qu’il y a deux blocs de maths pour la puissance et l’inverse, avec deux données de la figure, le point P et le curseur n, que l’on prend dans Expression, et un retour du résultat, item pris aussi dans la rubrique Expression.

Pour les personnes habituées à Blockly, vous pouvez le faire sans plus d’explication. Lire quand même rapidement le détail de la construction qui suit pour ses commentaires généraux sur l’interface.

Détails sur la réalisation et commentaires généraux

On commence par ouvrir l’item expression

Le premier item renvoie le script dans l’objet qui le porte, que ce soit une liste comme ici, ou un point. Nous y reviendrons régulièrement.

On notera la présence (item 3) d’un item générique d’objet muni d’un pop-up qui reprend tous les objets non cachés de la figure. L’item suivant (Valeur de) fait la même chose, mais peut être utile à choisir quand il y a beaucoup d’objets dans la figure car cet item permet de faire des tris d’objets. En général, sur des figures simples, on utilise l’item 3.

Vous pouvez glisser l’item Retourner, ainsi qu’un item d’objet de la figure (centré sur l’objet b ci-dessus, mais cela peut être autre chose lors de votre manipulation : le point P par exemple. Vous glissez aussi un item de la rubrique Maths pour faire une opération arithmétique.

Comme on a besoin d’un autre objet de la figure, on pourrait glisser à nouveau un item d’objet, mais on peut aussi dupliquer l’un de ceux déjà présents dans la fenêtre de script, par un clic droit ou un tap long.

Puis par le petit pop-up vous choisissez le point P dans l’une des items d’objet et la variable n (curseur) dans l’autre. Dans l’illustration ci-dessous, vous remarquerez les deux objets l1 et l2 : ce sont les représentations graphiques des listes a et b. l1 (de a) ne se voit pas, on a vu l2 (le rectangle associé à b). Nous allons rapidement mettre l1 en évidence.

Vous remarquerez que l’on a glissé aussi une constante de la rubrique maths, et qu’on a mis cette constante à 1. Le bloc d’opération arithmétique a été lui aussi dupliqué et les opérations choisies. Puis vous assemblez les blocs pour faire ce dont on a besoin, en choisissant les opérations dans le pop-up des opérations, pour obtenir ceci :

Alors, au moment où vous glissez l’expression de la racine n-ième de P dans le bloc de retour, vous obtenez instantanément la création des racines 361-èmes de P (si n vaut 361 comme ici), à la fois dans l’expression a, liste de points, mais aussi dans sa représentation graphique l1 qui est un objet graphique list de DGPad. Cette représentation est une liste de 361 points sur un cercle de rayon un peu plus grand que 1 (la racine n° du module de P comme nombre complexe), qui donne l’impression d’être un cercle.

(fin du bloc détaillant la première expression)


3. Réalisation de la figure finale

On commence par prendre un point sur la liste l1 des racines n-ème de P. Comme il faut que ce point soit nommé, autant le faire avant. Pour cela commencer par sélectionner l’outil de nommage d’objets (l’icône A du tableau de bord en bas de l’écran) et cliquer sur la liste l1. Il y a des possibilités de comportement et la seule possibilité de création (l’icône point) est la création d’un point sur objet.

Alternative pour nommer le point : On pouvait aussi créer le point sans nommage automatique et ensuite, avec l’inspecteur d’objet (la roue du tableau de bord), ajouter un nom et diminuer la taille de la police.

Penser ensuite à désélectionner l’icône de nommage. Puis ouvrir Blockly sur la liste b. Si ce n’est pas possible c’est que vous avez quitté le mode consultation, cliquer à nouveau sur le pointeur à gauche du tableau de bord.

Dans le bloc associé à b, nous allons construire ce script, qui précise la définition de cette liste.

Pour les personnes qui ont l’habitude de Blockly, cela devrait être assez immédiat. Vous aurez noté le code couleur : en marron, des objets de la figure, que l’on place sur la fenêtre de script avec l’item d’objet, item 3 de la rubrique Expressions, en pourpre les variables locales (le compteur i) de la rubrique Variables. Pour les lecteurs moins familiers de Blockly, voici une aide pas à pas.

Détails pour la construction des puissances de A


Création d’une nouvelle liste

Commencer par créer une nouvelle liste, à partir de la rubrique Listes

et lui donner un nouveau nom en créant une variable

Créer le compteur

Pour personnaliser le compteur (de la rubrique Boucles), glisser (de la rubrique Expressions) la variable n : pour cela prendre l’item d’objet qui peut être centré sur un autre objet, et, sur la fenêtre de script, avec le pop-up le changer en la variable n avant de glisser le bloc dans le compteur.

En glissant n à la place de 10, il prend sa place et éjecte donc la constante. Mettre alors la constante 10 à la corbeille ou sur la partie gauche de l’interface Blockly qui sert aussi de corbeille.

Ajouter un terme à la fin de la liste en cours de création.

Toujours dans la rubrique liste, prendre l’outil de push en fin de liste et préciser la liste utilisée.

Vous remarquerez que la liste est sur une liste par défaut. Certains utilisateurs de Blockly préfèrent cette façon de faire (laisser une liste item par défaut), pour ne pas oublier de changer la liste, d’autres suppriment cette liste par défaut simplement en la renommant à la première création.

Enfin compléter ce qui doit être ajouté à la liste, c’est-à-dire la puissance i-ème de A. La variable i est une variable locale, on la prend donc dans la rubrique Variables, pour la placer dans l’expression mathématique préalablement déposée sur la fenêtre de script.

Il ne reste plus qu’à finaliser ...

(fin du bloc d’explication)


Placement du dernier dernier bloc

Pour les personnes qui parcourent seulement l’article, voici ce qu’il se passe lors de la pose du dernier bloc :

Avant la pose de la variable de retour

Après : la liste et sa représentation graphique sont créées instantanément (pas de « drapeau vert » pour lancer un script) : la PVD est aussi Dynamique dans sa propre création.

Fermer l’interface de Blockly. Vous pouvez enregistrer votre première figure de programmation visuelle dynamique avec l’icône d’envoi à gauche du premier nuage. Lui préférer une extension .dgp au lieu du .txt classique, cela passe mieux dans certains clients de messagerie par exemple.

Améliorations cosmétiques de la figure

On peut améliorer la présentation. C’est l’occasion de voir un minimum d’outils du logiciel.

• On peut cacher les deux expressions a et b avec la gomme : l’outil gomme est un cacher/montrer ce n’est pas un outil supprimer comme dans GeoGebra, pour cela il y a une corbeille. Ne pas le faire tout de suite car on va revenir sur les blocs de b.
• L’inspecteur d’objets (icône roue) permet de modifier l’aspect des deux listes (graphiques). Se placer donc dans l’inspecteur d’objet, sélectionner la seconde liste, celle qui vient d’être créée, vous pouvez mettre les point à 0 et les segment à 0.5 ou 0.6 d’épaisseur. Tout est modifié en temps réel.

Rappel sur le déplacement de la figure

En mode consultation (aucun outil sélectionné), le clic de la souris dans la fenêtre du navigateur (ou un tap-move au doigt) déplace la figure.
En mode création (le pointeur standard activé), un clic droit à la souris déplace la figure, deux doigts en translation sur tablette.

Bizarrement, au moment où ces lignes sont écrites, la couleur, elle, n’est pas modifiée en temps réel. Probablement un bug dû au fait qu’on peut ajouter de la couleur dans la liste.

Retour dans le blockly de b

On peut ajouter des aspects de couleur (pour la liste graphique l2) directement dans l’expression b. La règle est que l’on ajoute un aspect couleur, toujours à la fin de la liste pendant sa création (par exemple dans des boucles imbriquées on peut en mettre un à la fin d’une boucle). Voici une version simple : préparer un ajout de RGB basique en désignant une couleur (les couleurs peuvent être algébriques, on verra cela ultérieurement). Puis glisser cet ajout juste après la création, on voit l’effet immédiat.

On peut ajouter une autre couleur à la fin, et alors la liste passe d’une couleur (autour du centre) à l’autre (à la périphérie).

La figure finale en ligne : https://huit.re/BLK01b


Haut de la barre d’analyse de la PV


Analyse PV | Aspects Dynamiques de la PV | Récursivité dans le Blockly de DGPad

2. Philosophie de DGPad – Prise en main succincte.

Pour manipuler en ligne : http://www.dgpad.net/index.php

DGPad est une application de géométrie dynamique orientée tactile, écrite pour Android et iOS, mais disponible aussi en WebApp sur ordinateur. Elle a l’avantage, en particulier sur tablette, d’être entièrement en anticipation des constructions, y compris dans son module de tracé de courbes ce qui peut être l’occasion, en lycée, d’explorer les fonctions autrement que ce qui peut se faire généralement.

Cette partie propose de présenter non pas les fonctionnalités du logiciel (on donnera des liens d’autres sites sur la question), mais le minimum à connaitre pour travailler rapidement avec le logiciel, et en particulier pour utiliser la PVD.

Outils infixés - Interface

Outils infixés

Vous avez probablement pratiqué GGB ou, les plus anciens, Cabri-géomètre, ou encore CaRMetal : tous ces logiciels ont une interface classique pour leurs outils : on dit que les outils sont préfixés : on choisit d’abord l’outil puis les objets associés. On ne s’en aperçoit pas toujours (à force si quand même) car on a l’habitude et on va assez vite mais cette interface est particulièrement « gourmande en clic », surtout s’il y a des menus déroulants comme dans les deux premiers cités.

L’auteur de DGPad a réfléchi à une interface plus efficace nécessitant moins de contact (de « touch ») sur tablette, ou clic de souris sur ordinateur. Il a choisi une approche radicalement nouvelle, celle des palettes contextuelles à la situation. Informatiquement, c’est le choix d’une programmation objet, centrée sur les objets géométriques et non plus sur les outils. C’est comme si on venait réveiller un objet (point, droite, segment, polygone, cercle) et qu’il nous proposait tout ce qu’on peut faire avec lui. Les palettes sont donc différentes pour un point, une droite, un segment, un cercle …

La palette la plus complète est la palette des points : 16 actions sont possibles à partir d’un point : les deux lignes de cette palette au dessus du point.

La palette en dessous du point est la palette des comportements, nous y reviendrons dans le prochain onglet. Voici la différence entre les palettes de segments et de droites :

Conceptuellement, on peut dire que l’on passe d’une interface où les outils étaient préfixés (tous les autres logiciels de GD), à une interface où ils sont infixés. C’est une nouvelle habitude à prendre surtout pour les outils à trois entrées ou plus (cercle circonscrit, angle, polygone) : le pointeur tactile - le doigt - ne se comporte pas comme une souris : quand on lève le doigt, le système ne sait pas où il va apparaître, alors qu’il sait toujours où est le pointeur de la souris même si on ne clique pas dessus : on passe d’un pointeur à existence continue (ordinateur) à un pointeur à existence discontinue (tablette). L’interface doit en tenir compte pour forcer le lieu où l’on attend le pointeur pour conserver des constructions en anticipation - avec un « fil à la patte ».

Tableau de bord - Modes consultation ou création

Le tableau de bord est généralement sélectionné sur un item donné. Or la plupart sont des interrupteurs, on peut les désactiver, et quand aucun outil n’est sélectionné, on est en mode consultation : on peut agir sur la figure sans créer des points par inadvertance : le mode consultation est une nécessité de cette interface préfixée très ouverte, elle est donc un point important de l’interface..

Dans ce mode consultation, en particulier le repère 3D est plus rapide et il ne se déplace qu’à un doigt (tablette-trackpad) ou clic-gauche-glisser (souris) au lieu de deux doigts (respectivement clic-droit-glisser). Quand on charge une figure, par défaut elle est en mode consultation. Un « tap » (un clic sur ordi) sur un item du tableau de bord l’application passe en mode standard (ou mode création d’objets). A priori choisir par défaut le pointeur standard à gauche, pour créer des points, les autres items ont des fonctionnalités plus spécifiques.

Deux remarques :
• En classe - surtout sur tablette - on peut apprendre aux élèves à passer d’un mode à l’autre rapidement pour manipuler la figure « en consultation ».
• Le switch des items fait que, quand on n’y pense pas, on quitte souvent le mode création en désactivant un item, passant alors sans s’en rendre compte, en mode consultation. Sélectionner alors à nouveau le pointeur standard.

Exemple de l’intérêt du mode consultation : les 11 patrons du cube

Rappel : en mode consultation le repère se déplace par un tap-glisser ou un clic-glisser.

Vous pouvez enregistrer toutes les figures proposées en consultation en ligne avec l’icône d’enregistrement, à gauche du premier nuage. Préférez la nouvelle extension .dgp à l’extension .txt. Vous pouvez ensuite simplement glisser la figure sur un navigateur avec DGPad ouvert ou utiliser les applications sur tablettes. Toutefois, au moment où cet article est écrit, les MAJ tablette avec la version comprenant l’extension Blockly ne sont pas encore disponibles.

En classe un mode projection (dans l’interface générique de l’inspecteur d’objet) permet aux élèves de suivre sur l’écran de projection l’emplacement de la personne qui pilote DGPad sur une tablette. Le doigt sur la tablette est symbolisé par un cercle jaune.

Haut de la barre « Prise en main de DGPad » (pour onglet suivant)
Barre suivante : Aspects dynamiques de la PV

Palette de comportements

Palette de comportements

L’une des palettes les plus complètes est celle-ci, celle d’un point de base :

Cette palette contient de nombreux outils complémentaires, ou des raccourcis d’accès à d’autres outils, même si cet article ne parle que du nouveau comportement, Blockly.

Il faut bien voir que l’application est d’abord conçue pour les tablettes, donc les outils sont parfois centrés « tablette ». C’est le cas du premier à gauche : le placement du nom d’un point. On tourne le doigt (ou la souris) autour d’un point, le nom se place au symétrique par rapport au point (pour qu’on le voie avec le doigt).

Le comportement d’ancrage - et l’animation

L’ancrage peut servir à plusieurs comportements, mais en particulier pour fixer un point sur objet ou enlever cette dépendance. Voici un exemple d’un point que l’on place sur un cercle pour ensuite l’animer. On remarquera que la palette de comportement est encore contextuelle : un ressort d’animation apparaît et l’icône de dé-ancrage prend la place de l’icône d’ancrage.

Les plus anciens des lecteurs auront remarqué un curseur proche de celui de Cabri-Géométre, en hommage à ce logiciel pionnier et son auteur Jean-Marie Laborde : dans une autre vie, l’auteur de DGPad a été le « rédacteur en chef » (si si) d’une revue papier consacrée à Cabri-géomètre qui s’appelait abraCAdaBRI, qui a existé 3 ans (de 1993 à 1996), avant le site du même nom. Les logiciels ont bien progressé depuis, en particulier les animations des nouveaux logiciels de géométrie dynamiques peuvent être asynchrone : dans DGPad, on peut continuer la figure pendant plusieurs animations. Nous allons le faire un peu plus loin ... dans un script Blockly.

Mais l’ancrage sert aussi à faire des figures plus propres, en particulier pour ancrer une série de paramètres. Par exemple, dans la figure ci-dessous, des curseurs sont ancrés à deux points (poignée et trajectoire) ce qui permet de tout déplacer d’un coup si nécessaire. Comme cette figure est en 3D, les deux points d’ancrage des paramètres sont en plus des points flottants (comportement punaise), c’est-à-dire positionnés par rapport à la fenêtre, ils ne se déplacent pas (en 2D ou 3D) quand on modifie le repère 3D.

Commentaire sur la figure : on est dans le cas d’un point répulsif d’un système différentiel. La construction 3D de la courbe intégrale (approchée par Runge Kutta, car non intégrable) permet de voir que la solution longe temporellement (longuement selon la position de M) le point d’équilibre qui finit par expulser la solution vers l’un des deux autres points attractifs du système différentiel, suivant la position de la condition initiale M.

Manipuler cette figure en ligne

Manipuler une variante animée pour voir le déplacement dans le temps.

Sur ces figures, réalisées pour un cours de maths en biologie, le champ de vecteurs, la trajectoire (verte) dans le plan de phase et la courbe intégrale (rouge) sont réalisés avec Blockly. Nous y reviendrons brièvement.

Le comportement Aimantation

Parmi les autres comportements, l’aimantation est très intéressante : elle permet de finaliser des simulations qui correspondent soit à un projet mathématique, soit à un projet didactique.
Fondamentalement on peut aimanter un point à plusieurs objets à des puissances différentes.

Exemple d’utilisation didactique

On veut illustrer le fait que si H est orthocentre de ABC alors tout point, A, B, ou C est aussi orthocentre du triangle formé par les trois autres points. L’intérêt de cet exercice est que les côtés des triangles et les hauteurs changent seulement de statut, mais les droites restent statiques.

Dans la figure suivante, un point H est aimanté par l’orthocentre d’un triangle et par les trois sommets du triangle, En déplaçant le point H on voit que les poins A, B et C changent de place mais que les droites ne bougent pas. C’est l’occasion de faire parler les élèves sur cette figure (à partir de la 4°)

Figure en ligne du quadrilatère orthocentrique

Il y a ainsi de nombreuses possibilités d’usage élémentaire mais très efficace de cette aimantation.

Exemple d’utilisation mathématique

Illustrer le résultat proposé dans la figure suivante n’est pas vraiment possible, car pour passer par le point qui réalise la propriété il faudrait que le point M passe « exactement » (au sens informatique du terme, soit à la précision de l’ordinateur) par le point de coordonnée (x(B)-x(A))/(ln(x(B))-ln(x(A))). C’est impossible. Mais si on aimante le point M sur ce point à 1 ou 2 pixel pour laisser l’impression de la continuité, alors on illustre le fait que les droites sont parallèles quand l’aire du triangle est maximale.

Figure en ligne de l’aire sous la courbe ln

Haut de la barre « Prise en main de DGPad » (pour onglet suivant)
Barre suivante : Aspects dynamiques de la PV

Expressions

Les expressions

Les expressions permettent tous les calculs usuels que l’on peut avoir à faire dans une figure. Un clavier mathématique apparaît dans ce mode. Si l’une des variables x, y, z ou t est utilisée, l’expression devient une fonction et peut être tracée. Les courbes paramétrées 2D sont simplement une liste à deux termes de deux fonctions. Les expressions sont le lieu de construction des curseurs (il suffit de documenter min et max) des points en 3D (liste à trois termes).

Prise en main des expressions

On peut choisir soit l’icône de calculatrice dans le tableau de bord, soit la même icône dans la palette de comportement. Un menu de création d’expression a toutefois été récemment installé : clic (ou tap long) sur la page de DGPad

Cela permet de rentrer plus vite dans le mode expression, en particulier pour créer des listes.

Il faut toujours valider une expression par le bouton vert ou l’icône de représentation graphique. Comme tout est réalisé en temps réel, on oublie assez souvent qu’il faut valider ce que l’on voit sous nos yeux.

Les points de DGPad sont des listes de 2 ou 3 éléments, et donc x(A) s’écrit A[0], y(A), A[1] et en 3D z(A) est A[2]. Mais avec l’interface Blockly c’est désormais plus transparent.

Copier-coller : même procédure sur tablette et ordinateur

Pour ce qui est des expressions la principale différence entre les tablettes et les ordinateurs est le clavier : le copier-coller nécessite le changement de clavier sur tablette, et bien entendu pas sur ordinateur. Comme le comportement est identique sur les deux environnements, il en résulte que, sur ordinateur, il faut aussi utiliser l’icône clavier (qui échange les claviers sur tablette) pour que le copier ou coller soit opérationnel.

Exemple de figure alliant à la fois les curseurs et les listes

C’est une activité de type épistémologique, pour le lycée, sur les suites géométriques, en introduction - ou en second regard selon le contexte - à la fonction logarithme à partir de f(x)=1/x.

Grégoire de Saint Vincent (1625) a remarqué que si des points de l’hyperbole y = 1/x ont des abscisses en progression géométrique, la somme des aires [des rectangles sous la courbe] correspondantes est en progression arithmétique. Pour 1 ≤ a < b, on notera dans la suite A (a, b) l’aire sous l’hyperbole entre les points d’abscisse a et b. On notera la fonction inconnue de l’aire sous la courbe à partir de l’abscisse 1 par f(x) = A (1, x). Soit k > 1, on subdivise l’intervalle [a, b] avec b = k×a en n parties en progression géométrique de raison q comme indiqué sur la figure. On obtient le résultat (sommes de Riemann avant l’heure) indiqué sur l’illustration ci-dessous.

Manipuler la figure en ligne (ch permet de travailler sur les rectangles en dessous ou au dessus de la courbe)

Fermat, 25 ans plus tard, soit en1650, en a déduit que la fonction f(x) = A(1,x) vérifie la propriété algébrique des logarithmes.

En effet, pour x et y > 1, on peut exprimer A (1, xy) à partir de A (1, x) et A (x, xy). Il écrivit A (1, xy) = A (1, x) + A (x, xy) : c’est la relation de Chasles « heuristique » sur les aires (positives). Or d’après ce qui précède, A (x, xy) = A (1, y) d’où le résultat.

On a donc f(xy) = f(x)+f(y), relation fondamentale du logarithme.

Pour les mordus du JavaScript - ou par curiosité pour voir la différence avec Blockly

Le code de la liste des rectangles des sommes de Riemann peut être celui-ci. C’est un peu moins simple que d’ordinaire, car deux points dépendent du choix de ch, d’où une écriture booléenne de vy.

  1. var a=[A[0],A[1]];var tab=[a];for (var i=1;i<=n;i++){var vy=(ch==0)*(1/(a[0]*q))+(ch==1)*(1/a[0]);var b=[a[0]*q,0];var c=[a[0]*q,vy];var d=[a[0],vy];var e=[NaN,NaN];tab.push(b,c,d,a,e);a=b};tab

Pour pouvoir colorier les rectangles, l’ordre b, c, d, a est important. la variable e est une rupture de liste. Pour des listes de segments c’est important, cela permet de démarrer une nouvelle séquence de segments de la liste. Ici cela permet de clore un rectangle et donc de pouvoir colorier son intérieur.

Plus précisément, c’est parce que tous les points (b et a) de chaque séquence sont à l’horizontale qu’on n’a pas besoin de clore complétement la séquence, donc de terminer par b. Dans un cadre géométrique plus général, ce serait nécessaire comme on le verra sur la fractale de Pythagore en Blockly.


Où est ce LaTeX dans DGPad ?

Finalement l’outil widget n’est pas vraiment documenté. On peut y mettre beaucoup de choses, dont du html, du CSS et du LaTeX. Le LaTeX retenu, en particulier pour les tablettes est le KA-TeX (pour Khan Academy) qui est environ 30 fois plus rapide que le mathTeXt utilisé avant, mais qui, hélas, ne comporte pas encore tout, et en particulier pas les vecteurs à deux lettres, le overrightarrow. L’utilisation est standard.

Un peu plus loin sur les widgets - pour une seconde lecture ;-)

On peut faire beaucoup beaucoup de choses avec les widgets. Son nom vient du fait qu’on y peut mettre tout widget dans DGPad, aussi bien la météo de votre ville que le widget de Wolfram Alpha. L’intérêt est qu’il y a possibilité d’interfacer toutes sortes de contrôles en JS avec les expressions. Il faudrait écrire un article sur le sujet au moins pour documenter cet outil. Cela n’a pas été fait car l’auteur trouve que pour le moment, c’est une interface pour geek, juste donnée pour qu’on rentre du LaTeX dans les figures.

Un exemple de chose très surprenante que l’on peut faire : donner une consigne de construction simplement en présentant la figure à construire dans un widget : DGPad peut être mis dans un widget de DGPad, même en 3D comme dans cette figure de démonstration. Dans le widget, un clic droit déplace le repère 3D du widget bien entendu indépendamment du repère 3D de la figure.

Un lien sur les diverses possibilités des expressions avant Blockly

Pour une utilisation détaillée de ces points, on peut relire cette partie d’un ancien article du site de l’IREM de la Réunion. Plus précisément les quatre premiers onglets, car la suite se fait de manière différente et plus simple désormais (mais plus longue aussi). C’est impressionnant comme l’évolution d’un logiciel peut se faire ...

Avec l’implémentation de Blockly dans DGPad, l’affichage des listes a encore été optimisé dans DGPad à cause de l’usage massif que l’on peut en faire avec Blockly.

Haut de la barre « Prise en main de DGPad » (pour onglet suivant)
Barre suivante : Aspects dynamiques de la PV

La 3D

DGPad n’est pas un logiciel de 3D comme peuvent l’être Cabri 3D ou GeoGebra 5.xx, c’est plutôt un logiciel 3D « du point ». Mais il est plus simple d’utilisation et permet des figures rapides à faire et facilement utilisables. Ce qui est impressionnant avec DGPad, c’est la façon dont est gérée la 3D. Cela mérite une petite narration, même si, probablement beaucoup d’applications 3D sur smartphone utilisent cette méthode..

La 3D de DGPad - une belle histoire

Je vous la fait quand même courte. Les détails (post d’origine, réflexion progressive autour du principe) ont déjà été détaillés dans d’autres articles, y compris de MathémaTICE).

L’idée générale est que, si on perd de l’information quand on représente un point de 3D en 2D, en revanche, avec la représentation plane de ce même point dans deux positions du repère 3D, les coordonnées planes de ce point, dans les deux positions permettent de calculer les vraies coordonnées 3D du point. Une fois cela acquis (il fallait y penser, merci à Jérôme qui a initié l’idée), pour conserver une coordonnée dynamique 3D d’un point que l’on déplace, il faudrait faire cela en permanence, c’est-à-dire avoir un trièdre vibrant.

Fort des Scripts de CaRMetal, c’est ce qu’a fait Pierre Marc Mazat, dans cet article, un peu geek certes, mais en même temps très pédagogue, intitulé Une bonne vibration pour la 3D, de mars 2011. GGB 5 n’existant pas à l’époque, j’avoue avoir utilisé pendant 2 ans cette méthode pour présenter de la géométrie 3D dynamique dans mes cours.

Depuis, l’approche a été optimisée (on n’a plus besoin d’inverser une matrice 3x3 donc cela va plus vite), et elle a été implémentée dans DGPad en novembre 2013, comme méthode de représentation 3D du logiciel (l’application n’était encore qu’une webApp et pas une application Android et iOS). Quelques exemples en ligne qui rendent compte de la précision du calcul (à la précision du JS soit 10^(-12)) sont disponibles dans cet article de l’époque : Bonnes vibrations : le retour ... et l’implémentation.

Ainsi parti d’une remarque d’un post d’un utilisateur sur un forum, l’idée a cheminée pour devenir dynamique, mais un peu lourde à implémenter dans un logiciel qui n’était pas conçu pour, jusqu’à l’implémentation interne dans un autre logiciel pour lequel c’est la méthode de calcul 3D : la géométrie dynamique, finalement au service d’elle-même pour sa propre expansion.

Utilisation - autres exemples

L’utilisation des macros 3D est décrite dans l’article précédent. Là encore, l’arrivée de Blockly permet une programmation probablement plus systématique, même si les expressions permettaient déjà de jolies figures comme ce ruban de Moebius à k-tours dont le code est détaillé dans ce petit article sur le bilan des nouveautés de DGPad à la rentrée 2014. Pour s’entrainer, on peut s’amuser à le refaire en Blockly. Plus loin nous y apporterons une petite touche « Blockly » supplémentaire ...

Plus simplement et plus proche d’une utilisation en collège, signalons que l’utilisation de l’écriture formelle de point fonctionne très bien dans DGPad, Ainsi, y compris en 3D, la construction du quatrième point d’un parallélogramme ABCD, s’écrit avec l’expression A+C-B.

Rien qu’avec cette écriture, il est très facile de réaliser cette figure de base des 3 pyramides dans un cube.

Manipuler la figure en ligne : https://huit.re/PyraCube

Ce n’est pas nécessairement une écriture qui doit respecter les règles de la notation de Grassmann, c’est plus une écriture informatique que mathématique. On peut aller bien entendu très loin dans la pratique des calculs. Par exemple dans cet article sur les calculs de trajets optimaux de parcours d’une boite sans couvercle parmi les 9 patrons possibles, on doit faire différents pliages de trajets sur les faces. On peut ainsi faire ce type de calculs (M2 et N2 sont les points du sol dans le patron 2 des points M et N sur les faces, M2v est le point sur associé sur une face :

et ensuite (coordonnées de p2gAv ... par matrice) ... où l’on comprend qu’un logiciel 2D++ permet de faire beaucoup de choses mais n’est pas un logiciel de 3D, il faut le faire à la main ;-)

Lancer la figure générique en ligne

Une nano échappée hyperbolique

Pour le plaisir géométrique, pour montrer la capacité 3D du logiciel : les hauteurs et les médianes ou le cercle circonscrit sur la pseudosphère, surface à courbure constante négative la plus simple dont la géométrie naturelle (intrinsèque) est hyperbolique.

Ces figures ont déjà été faites en Cabri 2D (en 2003), en perspective cavalière, puis, en 3D en CaRMetal (en 2008) et en DGPad en 2013 : le fait que si on le souhaite, « tout » soit une liste dans DGPad rend cette réalisation bien plus efficace et ces figures demandent en général deux fois moins d’objet en DGPad qu’en CaRMetal car toutes les macros, même d’objets complexes, ne sont quasiment que des traitement de listes. C’est surprenant pour un géomètre, mais d’une étonnante efficacité !

Les versions les plus abouties sont encore celles de CaRMetal car, avec lui, on peut gérer l’enroulement des points sur plusieurs tours de la pseudosphère. Techniquement, c’est déjà accessible avec Blockly, mais il faut attendre que l’environnement progresse, comme par exemple la réalisation puis l’exportation de macros contenant du Blockly, pour atteindre le même niveau de finition sous DGPad que sous CaRMetal.

Cercles inscrit et exinscrits sur la pseudosphère (pas pour tablette).

Haut de la barre « Prise en main de DGPad »


Intro PV | Philo et prise en main de DGPad | Récursivité dans le Blockly de DGPad

3. Les Aspects dynamiques de la programmation visuelle.

Rappel : il est conseillé d’avoir lu, éventuellement effectué, la première prise en main de Blockly dans DGPad, détaillée au dernier onglet de la première barre d’onglets

Manip objet en prog.

Choix en manipulation directe d’objets géométriques pendant la programmation

Pour faire la manipulation (élémentaire) en ligne en temps réel, télécharger, dans une autre page, voire un autre navigateur (mais il faut recopier le lien), cette page : https://huit.re/Fil01
Rappel important : il faut activer le pointeur standard à gauche pour pouvoir agir sur la figure

On part de la situation suivante :

On a commencé un tableau de fils classique, à partir d’une fonction qui renvoie la liste qu’elle reçoit en la complétant. La réalisation de cette fonction en classe de seconde ou de première serait l’occasion de travailler la géométrie repérée - dans le cadre d’un projet spécifique car - dans un contexte non standard, le repère étant ni orthogonal ni normé : il est affine, mais on n’a pas besoin de le savoir pour calculer, dans le repère associé aux fils, les coordonnées des points nécessaires à la construction. L’activité peut être juste centrée sur les deux lignes compactées.

Dans la liste rendue, on notera le ciseau, qui symbolise la rupture de la liste, commandée par le bloc Rompre la liste. En effet, faisant un tableau de fils - ce serait la même démarche pour un champ de vecteurs - on fait une liste de segments et on indique qu’on ne relie que deux points. Donc il y a une rupture tous les deux points. C’est sans effet sur la vitesse d’exécution pour quelques centaines de segments.

L’objectif de la manipulation suivante va être, en copiant-collant la ligne d’instruction qui commence par la fonction tableau de fils, d’illustrer plusieurs choses :
• l’action immédiate sur la figure quand on exécute une modification. Mais ça, on l’avait vu lors de la première activité.
• si on le souhaite, les modifications dans les paramètres des blocs de Blockly peuvent être désignés en manipulation directe dans la figure : au lieu de changer par un pop-up B en C, on peut cliquer sur le point C dans la figure.

C’est donc cette manipulation que l’on propose en détail dans le bloc suivant

Détail de la réalisation finale de la figure

1. Préparation de la figure

Pour accéder à la fois à la figure DGPad et aux blocs de Blockly, il faut organiser son écran, et positionner l’éditeur de blocs par exemple de cette façon (en taille réduite) :

2. Duplication et modification des paramètres

Puis vous dupliquez le bloc d’appel de la fonction

et vous modifiez le premier paramètre en mettant B à la place de A :

Pour le point C, même si ici c’est un peu plus long, je vous propose de tester l’autre façon de faire, plus en manipulation directe sur la figure, c’est-à-dire de montrer C à la souris ou au doigt. C’est un peu plus long, car il faut effectivement, dans ce cas, sélectionner le bloc de droite contenant actuellement le point B (et c’est plus facile de la changer que juste le sélectionner ;-)

et une fois sélectionné, vous allez cliquer sur le point C, au lâcher du doigt ou au clic de souris, la procédure de tableau de fils adapte la construction (qui était faite mais sur la précédente, dès que le bloc dupliqué avait été placé sous le précédent).

3. Finalisation de la figure

Vous poursuivez en dupliquant à nouveau deux fois le bloc et en adaptant les paramètres de la fonction tableau.

(fin du bloc)


La figure finale : https://huit.re/Fil02 (coloriée)
(pas nécessairement significative, c’est plus les possibilités de l’interface que l’on voulait présenter ici).

Haut de la barre « Aspects dynamiques de la PV »
Barre suivante : Récursivité dans le Blockly de DGPad

Modif code dans Anim

Exemple de modification du code pendant une animation multiple

On considère cette figure initiale (avec deux animations) : https://huit.re/Tournesol1

Pendant les animations, on va (vous allez si vous le souhaitez) modifier algébriquement, la taille des points.
Pour cela, ouvrir - donc pendant l’animation - les blocs associés à la liste de points.

Rappel : ne pas oublier d’activer la flèche à gauche pour pouvoir travailler sur la figure.

Dans ce code, vous allez ajouter un élément graphique : la taille des points définie par l’angle en cours comme dans cet exemple.

Vous le glissez après le « Rajouter » de la boucle « faire ». Ainsi la taille des points est fonction de l’angle. On peut prendre à la main, dans le curseur, l’angle pour voir la taille des points. Cela donne ceci :

Remarque : vous pouvez modifier la vitesse d’animation en allant dans l’inspecteur d’objets et en sélectionnant soit sur le curseur n du nombre de points soit sur le curseur de l’angle.

La figure finale : https://huit.re/Tournesol2

Haut de la barre « Aspects dynamiques de la PV »
Barre suivante : Récursivité dans le Blockly de DGPad

Algébr. aspects

Deux exemples d’algébrisation des aspects

Dans cet onglet nous allons travailler pour la première fois sur un point. Dans le cas du point, la fenêtre de script de Blockly dispose de plusieurs onglets :

Par défaut, l’onglet sélectionné à l’ouverture est l’onglet Déplacé. Mais on peut utiliser deux autres onglets Appuyé (correspondant au OnMouseDown ou au TapStart) et Relaché (équivalent de onMouseUp ou TapEnd). On peut donc avoir une gestion fine de la façon de traiter le comportement de la figure. En particulier pour une manipulation par des enfants sur une figure, où il est important de ne lancer l’action que quand une condition est atteinte, on préfèrera mettre l’action dans Relaché, même si la mettre dans Déplacé serait correct pour une manipulation plus experte.

Exemple 1 : deux aspects algébrisés des points

Si vous le souhaitez, pour vous entrainer, vous pouvez faire cette figure directement depuis la page blanche de DGPad en ligne : www.dgpad.net/index.php

On se propose de modifier la taille et la transparence d’un point en fonction de sa position : ce n’est donc qu’un exercice de style. Prendre un point dans la figure. On n’est même pas obligé de le nommer. Si on le souhaite, le nommage de point a été détaillé dans la prise en main : dernier onglet de la première barre d’onglets. Par contre c’est intéressant d’afficher la grille de DGPad (dernière icône du tableau de bord)

Sur ce point, activer Blockly, et rentrer ces deux instructions (pour donner un exemple)

On voit en temps réel l’effet de chaque instruction quand on la finalise.
Fermer l’interface blockly et jouer avec la position du point. On veut vérifer un comportement comme celui-ci :

Pour celles et ceux qui veulent jouer à la figure sans avoir à la faire : https://huit.re/OpakTailleAlg

Exemple 2 : la couleur du ruban de Moebius en fonction de la position du repère.

Là encore c’est un exemple académique, juste pour illustrer les possibilités inclues dans cette extension Blockly de DGPad.

On se propose de colorier le ruban de Moebius en fonction des angles phi et theta du repère 3D. En effet toutes les données génériques de l’environnement de la figure sont accessibles par ce bloc :

Détail des blocs utilisés

Vous remarquerez (à nouveau) qu’il faut mettre l’aspect non pas dans la liste elle-même (moebiusH) mais bien dans sa représentation graphique, l’objet list l1.

La figure en ligne : https://huit.re/MoebiusBlockly
Dans cette figure, on a laissé visible toutes les données : les segments « verticaux » sont dans la liste b et les « horizontaux » dans a. La modification de la couleur n’est que sur les verticaux (liste b - hum ! les noms internes des listes semblent inversés).

Haut de la barre « Aspects dynamiques de la PV »
Barre suivante : Récursivité dans le Blockly de DGPad

Exemples d’itérations

Exemples d’itérations géométriques

Dans cet onglet, on aborde des figures plus abouties, dont certaines sont construites effectivement pour être utilisées dans l’enseignement : celles autour de Volterra. Cette partie sera volontairement détaillée, non pas pour être reconstruite, mais pour commenter les méthodes mises en oeuvre. Les personnes non concernées pourront juste apprécier les résultats et passer les détails. Deux autres figures sont proposées, plus simple à mettre en oeuvre.

Volterra : champ de vecteur, trajectoire par la méthode d’Euler, (puis Runge Kutta) courbe intégrale 3D et animation

Ces figures ont été faites comme mise en pratique du Blockly de DGPad pour un cours dispensé en avril 2016 (en L1 GéoSciences). D’une manière générale les figures sont fournies soit avec les expressions utilisées visibles, soit, cachées. Il suffit d’activer le menu Montrer/cacher (la gomme du tableau de bord) pour voir les expressions, clairement nommées. Dans les illustrations, elles sont visibles. Dans les figures à télécharger elles peuvent être à un autre endroit.

1. Le champ de vecteur en 2D

Cette illustration donne les formules du champ de vecteur dans le plan de phase (x,y). Le système différentiel est autonome : le temps n’intervient pas explicitement dans la définition du système.

Le champ de vecteurs est construit sur l’expression (la liste de segments) Champ, dont la représentation graphique s’appelle l1 (donnée par le logiciel). Vous noterez que l’aspect de la liste de segments est donnée par la première ligne qui fait de cette liste un champ de vecteurs avec l’aspect flèche appliqué à l1. Cet aspect a été conçu, de fait, pour ce cours, c’est aussi pour cela que c’est finalement le premier aspect d’objet qui n’existe que sous Blockly.

Dans la boucle intérieure, on construit un premier point (i,j), puis un second et ensuite il y a une rupture de la chaine pour que l’on puisse construire un vecteur depuis un autre point de la grille.

La figure en ligne : https://huit.re/Volterra1

2. La méthode d’Euler

La méthode d’Euler, facile d’accès, est la seule accessible en L1. On sait qu’elle n’est pas du tout efficace sur cette situation : sur la figure suivante, il faut un pas très faible et donc plus de 4200 étapes pour voir que la trajectoire se referme :


La figure en ligne : https://huit.re/Volterra3
(sur cette figure, mettre un pas vers 5/100 en diminuant fortement n pour voir que l’approximation par la méthode d’Euler s’éloigne de la trajectoire)

3. La courbe intégrale en 3D

Dans la figure suivante on s’intéresse à la courbe intégrale, (t, x(t),y(t)). Pour cela, comme tout est fait avec Runge Kutta d’ordre 4 qui nécessite beaucoup moins d’étapes, on a choisi de définir la trajectoire par le point M, puis on prend un point A sur cette trajectoire, et on s’intéresse à la courbe intégrale depuis A. Pour cela, en particulier pour avoir la temporalité, il faut refaire une trajectoire à partir de A (cachée). Le reste est immédiat comme on va le voir.

3.a. La situation générale

Détail du code des premiers éléments

3.b. Le code pour le champ de vecteurs en (y,z), le temps étant en x.

3.c. Le code Runge Kutta appliqué à M

Pour construire la seconde trajectoire cachée, il suffit de remplacer M par A dans le code précédent.


3.d. Le tracé de la trajectoire en fonction du temps

La fin de la figure se fait très facilement : à ’aide du pas et de l’itération temporelle, on déploie la trajectoire dans le temps

De là, en réaménageant les coordonnées, on peut ensuite construire les solutions sur les différents plans (x,y) et (y,z).

La figure 3D sans la relation temporelle : https://huit.re/Volterra3D

La figure 3D avec le temps : https://huit.re/Volterra3Dt

Complément : L’ajout du temps est intéressant surtout sur les systèmes où il y a un point répulsif comme indiqué dans un autre onglet : on y voit que les trajectoires mettent « du temps » pour sortir de l’attraction d’un point répulsif.

Version 3D du modèle dit « de compétition » dans le cas d’un point répulsif : https://huit.re/Competition3Dt1

Jouer avec des carrés

On commence par une itération classique sur un carré avec un paramètre k :

Manipuler la figure en ligne : https://huit.re/Iter1Carre


Puis on veut transformer ce carré en 4 carrés et surtout, mettre sur chaque quart de carré une couleur différente pour harmoniser le tout de cette façon :

Cette figure a été faite lors des tous premiers tests sur le Blockly de DGPad, elle mériterait d’être réécrite, et repensée autrement. En particulier on pourrait faire la construction avec 5 listes au lieu des 20 utilisées ici.

Manipuler la figure en ligne (deux listes visibles) : https://huit.re/Iter4Carres4Couleurs
Pour voir les autres listes il suffit de les rendre visibles avec la gomme (elles ne sont pas « complètement cachées »)

Voire le principe d’extraction

On prend simplement les objets de la liste a de 4 en 4 et on les place dans la liste b.

On voit bien que l’on pourrait mettre une seule liste extraite par couleur au lieu d’en avoir fait 4 ici, et donc rendre significativement plus réactive cette figure.

(fin du bloc)

Attracteur de Hénon

L’attracteur de Hénon est très simple à programmer, c’est une simple suite

Voir le code

Voir le code


Pour voir l’attracteur comme on le présente sur Wikipedia ou MathCurve il faut remplacer les segments par des points (dans l’inspecteur d’objets) ... et mettre le curseur à 2500 ou 3000. Ici l’objectif est tout simplement dans l’esthétique des tracés avec les segments. Signalons toutefois qu’une des raisons (hors celles présentées sur ces sites) de l’intérêt graphique de cet attracteur est qu’il a (lui aussi) un cycle d’ordre 3 très facile à attraper en manipulation directe :

Manipuler cette première version de l’attracteur : https://huit.re/Henon1

Version aimantée

On s’aperçoit vite que la représentation graphique est très riche (on est assez loin des maths ici) pour y0 proche de -1 (en étant supérieur) et 0 <x0 <1. Pour cela on peut même placer le point A sur un segment dont l’ordonnée est pilotée par un curseur. On obtient par exemple :

Manipuler cette seconde version aimantée : https://huit.re/HenonAimant

Haut de la barre « Aspects dynamiques de la PV »
Barre suivante : Récursivité dans le Blockly de DGPad

Blocs d’action

Avec cet onglet - et les suivants - on quitte la description de fonctionnalités de Blockly sous DGPAd ou d’utilisation de Blockly dans DGPad pour aborder des thèmes plus conceptuels.

Les deux points abordés ici ne sont pas nouveaux. Ils sont déjà disponibles dans CaRMetal et GeoGebra, sous forme de Script Action. La programmation avec Blockly est intéressante en ce sens qu’elle est syntaxiquement plus simple.

Blocs d’action : du statique au dynamique

La première chose que l’on réalise naturellement avec un script de comportement appliqué à un algorithme statique, c’est tout simplement de le rendre dynamique. La présentation désormais archétypique de cette capacité vient de Alain Busser sur l’algorithme de Héron pour le calcul de la racine carrée. On applique cet algorithme à l’abscisse d’un point sur l’axe des abcisses, et manipulant ce point, on trace naturellement, avec un algorithme statique, la représentation graphique de la fonction racine carrée.

L’algorithme de Héron version Blockly de DGPad

Précision sur la boucle tant que : comme tout est évalué et construit en temps réel, on prendra la précaution de ne pas construire « temporellement », c’est-à-dire pas à pas, le booléen de la boucle tant que directement dans la boucle elle-même : on construit cette expression à côté, et quand elle est finalisée, on la clipse dans l’item « tant que ».

On notera aussi la nécessité de traiter correctement - dans le si / sinon - le cas où l’on déplace le point M trop à gauche (ie lui donner une abscisse négative). En effet M ici est simplement un point sur l’axe. On aurait pu faire autrement, mais c’est l’occasion de montrer qu’il faut choisir entre limiter le mouvement d’un point (en le plaçant sur un segment) ou traiter algorithmiquement une plus grande liberté de mouvement de ce point.

Manipuler la figure en ligne : https://huit.re/Heron1

L’animation comme boucle infinie d’actions

Certes, que l’animation soit une action, en soi, est une trivialité. Et pourtant, le traitement que l’on en fait peut s’avérer original. Revenons sur la première figure proposée dans cet article, l’exemple de DGScript proposé par Eric Hakenholz : https://huit.re/lancer_deux_des

L’essentiel de ce qui se passe dans cette figure est traité dans un bloc de comportement de l’expression a, qui est simplement un nombre animé. Dans la version en ligne, a et b sont des expressions cachées, vous pouvez les rendre visibles avec l’outil gomme.

Voici le script du nombre animé a :

Une des premières choses qui peut surprendre est l’absence de boucle. En fait c’est l’animation de l’expression qui contient ce script qui sert de boucle infinie comme on les trouve dans les logiciels de programmation visuelle (Scratch, Snap, Tickle en ont ainsi que les sites de codage en ligne sous Blockly).

On note aussi la possibilité de donner une expression, tapée au clavier, ici pour la variable tab, dont le premier terme sert d’indentation pour déterminer le nombre de lancers effectifs. En effet l’expression « Nombre total de lancers » est égale à b[0] et la somme entre l’expression b (liste à 12 termes) et la variable tab.

Les lecteurs les plus curieux peuvent être surpris aussi de l’utilisation de la variable compteur (variable de script), pourtant non définie ici. Ce point est abordé dans le bloc dépliable suivant :

Compléments plus techniques

Cette figure comprend 4 boutons de type DGScript, munis chacun de ces quelques lignes de code

On remarque que la variable interne compteur, est définie et réinitialisée dans deux de ces scripts et qu’elle est modifiée dans le script de l’expression a.

Elle se comporte donc comme une variable globale. Au moment où cet article est écrit, les variables globales ne sont pas encore implémentées dans l’environnement Blockly de DGPad, mais on voit, sur ce petit hack interne que tout a déjà été préparé pour les accueillir.

A priori cette méthode n’est pas à utiliser pour le moment ’tant que" les variables globales ne sont pas explicitement proposées comme telles, mais on voit déjà que si on définit une variable dans un bloc et que l’on construit une variable de même nom dans un bloc de type GET d’un autre script, ces variables communiquent.

(fin du bloc)


Haut de la barre « Aspects dynamiques de la PV »
Barre suivante : Récursivité dans le Blockly de DGPad

Auto-référence

Les enjeux de l’auto-référence

La question de l’auto-référence des objets - ici des points et des expressions - n’est pas seulement un enjeu pratique, c’est aussi un enjeu théorique en rapport avec la question du déterminisme et de la continuité des manipulations dans une figure géométrique. Ce point a déjà été longuement abordé et détaillé autour de CaRMetal dans cet article sur la référence circulaire (avril 2009) ou cette version plus technique dans MathemaTICE : suspendre le temps en géométrie dynamique pour affiner l’investigation (septembre 2008), mais toutes ces présentations étaient avec des applets java intégrées à l’article, ce qui devient plus difficile à lire en ligne actuellement.

On reprend ici ce qui a été dit lors de la présentation de CaRMetal 3.5 (mai 2010 - onglets Dét. Cont. puis Circularité et Temps 1) en le détaillant un peu plus (dans des blocs dépliables) pour celles et ceux qui veulent approfondir.

Déterminisme et continuité

En géométrie dynamique, un logiciel est dit déterministe si la figure revient à sa position initiale quand ses objets constituants, après manipulation, sont replacés dans leur position de départ. Dans un cadre scolaire, il est clair que le déterminisme – avec d’autres propriétés comme un fonctionnement intrinsèquement affine dans la déformation des figures – est dans le noyau du cahier des charges d’un logiciel de GD. Une autre propriété est dans ce noyau, la continuité, pendant la manipulation directe, des intersections des objets.

Mais la continuité et le déterminisme dans le même cahier des charges, est-ce possible ? Ce problème est connu sous le nom de conjecture d’isotopie (Ringel 1956), infirmée par Mnev en 1985 (donc avant la création des logiciels de géométrie dynamique). En résumé (extrait de la thèse de Bernard Genevès - 2004 - Université Joseph Fourier de Grenoble - « Vers des spécifications formelles : fondements mathématiques et informatique pour la géométrie dynamique. ») :

« la continuité et le déterminisme des constructions sont incompatibles : il faut privilégier l’un ou l’autre, on ne peut maintenir les deux simultanément jusqu’à leurs conséquences. »


Maintenir la continuité - un premier outil

Une des tâches des pionniers de la géométrie dynamique a donc été de concilier les contraintes de déterminisme avec des choix de continuité. Non seulement on arrive, pour les figures usuelles (cercles / droites) à gérer correctement la continuité des intersections, mais Cabri a alors inventé deux types d’intersections, l’intersection d’objet et l’intersection « à la volée », où l’on désigne celle des deux intersection que l’on veut. Pour l’intersection d’une droite et d’un cercle, l’intersection à la volée (montrer à la souris le point que l’on veut prendre sur l’état de la figure à l’écran) résiste au passage à l’infini du rayon du cercle (« persistant namming problem »), alors que ce n’est pas le cas des points obtenus par intersection de deux objets, c’est-à-dire en montrant sccessivement les deux objets.

En terme de continuité, c’est une avancée importante qui a été reprise par les logiciels de nouvelle génération comme Geogebra et CaR. L’utilisateur retiendra que pour mieux préserver la continuité dans les figures, quand il y a plusieurs intersections, il est préférable de prendre l’intersection « à la volée ».

Et essayer d’aller plus loin (exemple GGB)

Mais ces deux logiciels ont fait un effort supplémentaire pour installer la continuité le plus loin possible. On sait d’avance qu’il n’y a pas de proposition totalement satisfaisante, mais cela n’empêche pas d’améliorer quelques outils. Dans Geogebra l’utilisateur peut « activer » une option de continuité générale à une figure. La continuité de l’intersection d’un cercle et d’une droite est satisfaite quand le cercle passe par un rayon infini, sans même qu’on ait fait l’intersection « à la volée ».

Plus subtil encore, le maintient d’une seule intersection, comme l’intersection d’un arc de cercle et d’une droite. Sans la continuité, le changement d’orientation de l’arc (correspondant à un passage à l’infini du rayon du cercle) fait perdre l’intersection, car c’est l’autre, non nommée qui apparaît, celle nommé est sur l’autre branche de cercle. Avec la continuité on a le « maintient du nom de l’intersection » pour reprendre le terme anglo-saxon de cette propriété :

Pourtant, sur l’intersection de deux cercles, même avec la continuité, on retrouve des problèmes, sur la simple construction du 4° point d’un parallélogramme.

Pour palier à cela CaRMetal, propose pour les points d’intersection, une personnalisation individuelle plus algorithmique. C’est en fait un outil développé par René Grothmann, pour gérer plus individuellement cette question du déterminisme et de la continuité. Cela a été détail dans l’onglet Exercice de cet article de présentation de CaRMetal.

(fin du bloc)

Rompre le déterminisme avec Blockly

On revient sur l’exemple archétypique du thermomètre à mémoire, déjà plusieurs présenté sous CaRMetal : sur une droite, horizontale, un point M déplace un point Min et un point Max tel que Min et Max gardent les traces des abscisses minimales et maximales respectivement quand M est déplacé par l’utilisateur (ou une figure en général).

On voit bien que cette figure là (par exemple impossible à réaliser avec Cabri et bien d’autres logiciels de géométrie dynamique) est une rupture du déterminisme décidé par l’utilisateur. Cette rupture est utile - et signifiative - dans différentes situations, nous allons l’illustrer, mais elle n’a vraiment d’intérêt que si on peut, par ailleurs réactiver le déterminisme quand on le souhaite. C’est donc ce que nous allons faire.

Auto-référence des points Min et Max

Dans cette figure, sur une droite horizontale pilotée par un point P, on place un point M. Les points Min et Max doivent être préalablement construits puisque les scripts de Blockly sont des scripts de comportement qui ne créent pas de points mais les modifient.

On peut alors, dans l’onglet de déplacement de M, écrire ce simple script :

Dans l’illustration suivante, sur chaque ligne, on a déplacé M vers la gauche, puis vers la droite.

Rétablissement du déterminisme

Ce rétablissement se fait par déplacement du point P :

Autrement dit les points Min et Max sont définis à la fois par eux-mêmes mais aussi par les points M et P, et ceci dans des scripts différents. En terme de sprites (ou lutins) cela correspond simplement à un échange d’informations et à leurs traitements. Avec M cela utilise nécessairement une auto-référence. Cela correspond plutôt au comportement d’un clone, même s’il n’y a pas du tout de clone ici.

Par rapport à ce que l’on peut faire avec CaRMetal, on peut noter une différence notable : dans CaRMetal, toute l’information sur le point Min est dans les coordonnées de ce point. Par exemple pour le rétablissement du déterminisme on peut écrire :
if(d(P)>0 ;x(M)-1 ;min(x(Min) ;x(M)))
(où d(P)>0 signifie que le point P vient d’être déplacé) : c’est encore de l’échange d’information mais celle-ci est centralisée et analysée dans le point Min.

Ici c’est assez différent puisque c’est dans un bloc de comportement du points P que son déplacement induit la modification des points Min et Max.

Pour ce qui est du déterminisme, si on est pointilleux, on observera qu’il n’est effectif précisément que lors d’une seconde utilisation : les points ne vont pas reprendre les positions de départ de la figure quand elle est téléchargée (mais ce serait possible, même avant la mise en oeuvre des variables globales). Le principe ici est plutot de se fixer une situation standard et y revenir. Dans la pratique, c’est largement suffisant, ce que l’on veut c’est quitter la bulle de « non déterminisme ».

Manipuler la figure en ligne : https://huit.re/Thermo1
(ne pas oublier d’activer le pointeur standard si vous voulez accéder aux blocs)

Un exemple d’utilisation scolaire

Au lycée, lors de l’entrée dans le concept de fonction, la perception des propriétés globales comme le minimum ou le maximum d’une fonction sur un intervalle pose régulièrement question. D’une manière plus générale il y a confusion entre les propriétés locales universelles (définies en un point et vraie sur un intervalle comme la dérivabilité par exemple) et les propriétés globales dont les définitions sont liées à l’ensemble des points de l’intervalle.

Une façon possible d’accompagner cette difficulté est d’en proposer une approche kinesthésique, soit de manière transférée avec lune souris, soit plus directement au doigt sur une tablette tactile : les élèves (éventuellement un seul avec une activité vidéo projetée si elle ne peut pas être individuelle) déplacent un point sur un intervalle et peuvent observer le minimum et le maximum de la fonction s’actualiser, avec la mémoire du min et du max comme présenté ci dessus.

En voici un exemple sur une fonction polynôme de degré 3 : l’intérêt est que l’on n’a pas de curseur, on n’est donc pas centré sur les aspects numériques mais seulement sur le concept que l’on veut mettre en oeuvre et sur l’idée que ce concept est réellement global, défini sur un intervalle.

Sur cette illustration on voit que c’est aussi l’occasion de vérifier qu’un extremum local n’est pas nécessairement global.

Utiliser la figure en ligne : https://huit.re/Extrema
(on réinitialise la fgiure en déplaçant un des quatre points A, B, C et D).

Détails du code utilisé


1. les points Min et Max

2. La réinitialisation


Exercice : modifier le code en faisant une figure très différente, qui n’est plus kinesthétique, mais qui finalement est plus fonctionnelle : on construit l’intervalle et il n’est pas réinitialisé mais il s’ajuste au contraire quand on agit sur A, B, C ou D.
Méthode : bien entendu il faut en permanence, parcourir l’intervalle [xA xD] et faire comme on l’a décrit dans le précédent onglet (animation comme boucle infinie).

Haut de la barre « Aspects dynamiques de la PV »

Réf croissées

Références croisées de points

En analysant le comportement de points que l’on peut produire sur d’autres, on voit bien que les échanges peuvent dans tous les sens. On se dit alors qu’il est naturellement possible d’avoir des échanges croisés et donc des références de coordonnées croisées.

Là encore, ce n’est pas nouveau, c’est déjà possible dans CaRMetal et GeoGebra, mais, dans les deux cas, de manière quand même assez ésotérique. Avec Blockly cela devient complètement naturel car très simple à écrire.

Voyons cela sur deux exemples

Pythagore à contrainte avec 3 points manipulables

Dans cet exemple, on se donne une longueur d’hypoténuse d’un triangle rectangle et on se propose de construire un tel triangle.

La construction euclidienne

C’est bien entendu élémentaire dans le contexte euclidien : on se donne deux points B et C, et un point A - sommet de l’angle droit - sur le cercle de diamètre [BC]. Plus précisément, si on cherche les degrés de liberté, on peut se donner B comme point de base, alors C est sur le cercle de centre B et de rayon l’hypothénuse. On a donc un point de base et deux points sur des cercles.

Une construction possible avec Blockly

On se propose ici de faire une construction avec les trois points agissant les uns sur les autres. On choisit que déplacer B permettra de déplacer C sans modifier A (donc différent de la version euclidienne), de même pour C : on modifiera B sans toucher à A. Et déplacer A modifiera B sans toucher à C : le script de A sera donc exactement celui de C.

Le script est alors très simple (on a mis plusieurs variables locales standard pour pouvoir faire des copier coller de bloc sur les scripts). Voici celui du point B et la figure en même temps :

On a laissé le nom PQ à la variable locale (au lieu de dPQ comme pour les autres) qui prend la valeur du segment PQ pour montrer que c’est tout à fait possible de réutiliser, localement, des noms d’objets déjà utilisés dans la figure, il n’y a pas d’interférence !
On a eu aussi la coquetterie d’utiliser les nombres complexes pour l’angle droit, juste pour illustrer cette possibilité, mais on pouvait ne pas faire comme cela.

Manipuler la figure en ligne : https://huit.re/Pythagore3ptsLibres

Exemple d’un polygone régulier dont tous les points sont manipulables

On se propose, cette fois, de construire un pentagone dont le centre et les 5 sommets sont modifiables. On voit bien ici que l’on va au delà des définitions classiques d’un polygone régulier, qui est défini par un centre et un point. Ici aussi, bien entendu, mais chaque sommet est utilisable pour la définition de l’objet.

Sur la figure suivante, on a ajouté des tracés de fils, pour que ce soit plus joli, et bien entendu cela ralenti la manipulation de la figure.

Le script du point A

r et cr sont les points de coordonnées de (cos 72°, sin 72°) et son conjugué. On aurait tout aussi bien les construire dans le script.
On a choisi ici une approche barycentrique. Dans ce script les 8 premières lignes sont communes à tous les points et pourraient être - quand cela existera - des variables globales. Cela a justement été rédigé pour que les premières lignes ne changent que pour les variables locales or et pt (origine et point de définition du pentagone).
De même on construit les 4 autres points de chaque bloc de la même façon, il n’y a que les références qui change : la encore s’il y avait des fonctions globales, on aurait pu en utiliser une.

Manipuler la figure en ligne : https://huit.re/Penta_6pointsLibres
(on a laissé la liste qui construit le tableau de fils, mais ce n’est pas ce qui compte ici)


Il est clair que ce type de figure gagnera en simplicité quand on disposera de variables et fonctions globales.


Haut de la barre « Aspects dynamiques de la PV »

Intro PV | Philo et prise en main de DGPad | Aspects Dynamiques de la PV

4. Récursivité dans le Blockly de DGPad)

Dans cette dernière partie, on revisite, de manière très classique, quelques standards usuels de la récursivité. En effet, a priori Blockly n’est pas nécessairement très doué pour la récursivité - même si on peut faire un calcul de factorielles. Comme c’est un point important en mathématiques, et en partiuclier pour les tracés de certaines courbes, l’auteur de DGPad a repris cette partie du code initial pour faire que la récursivité fonctionne trés bien, y compris quand elle est dans la dernière instruction des fonctions récursives.

Voici donc un petit tour d’horizon qui n’a aucune originalité particulière mais qui permet de voir les possibilités de l’extension Blockly dans DGPad dans ce domaine. L’objectif de cette barre d’onglets est autant de partager des figures que de montrer les possibilités récursives du Blockly de DGPad : en particulier, quand il y en a, les aspects techniques ne sont pas vraiment développés.

On commence par l’utilisation du bloc fonction

Arithmétique

Utilisation des fonctions Blockly dans DGPad

PGCD

La définition classique (ici version Python)

Version récursive identique avec Blockly

Utilisation de la figure en ligne : https://huit.re/PGCD_recursif

BEZOUT

L’algorithme (comme proposé dans le manuel de la TI N’Spire PDF orienté oral du CAPES)
Version Blankinship (1963)

Deux versions en Python

Version Blockly (avec commentaire de Eric Hakenholz sur ce code)

Ce qui donne (la liste est cachée)

Utilisation de la figure en ligne : https://huit.re/BezoutRecursif

Haut de la barre « Récursivité dans le Blockly de DGPad »

Sierpinsky

Le triangle de Sierpinsky

Sur une démarche très classique sur laquelle on peut comparer l’efficacité des logcieis, on notera ici que le niveau n=7 (à partir du triangle n=0) construit plus de 10000 objets tout en restant manipulable. C’est une performance qui mérite d’être soulignée.

On remarque que pour le tracé, on utilise 4 points : on ferme le triangle, cela permet de le colorier (avec une opacité 1).

Lancer la figure en ligne : https://huit.re/SierpinskyRec

Exercice

Modifier l’algorithme pour obtenir une couleur selon les directions de A, B ou C comme ci-dessous : à chaque niveau c’est bleu du côté de A, rouge du côté de B et vert du côté de C (ci-dessous fait en CaRScript, les scripts de CaRMetal).

Haut de la barre « Récursivité dans le Blockly de DGPad »

Cesaro

La courbe de Césaro

Sur cette page de son collège, Julien Pavageau propose cette présentation de la courbe de Césaro, adaptée au collège.

Construction Blockly

Dans le cas général, avec un segment [AB] quelconque, les calculs sont plus techniques :

Lancer la figure en ligne : https://huit.re/Cesaro

Remplissage

Il suffit de donner de l’opacité à la construction pour obtenir quelque chose comme cela :

Haut de la barre « Récursivité dans le Blockly de DGPad »

Fractale de Pythagore

Fractale de Pythagore

Commençons par des figures faites sans Blockly avant de se lancer dans la PVD

Une première construction classique avec une macro-construction

En effet, on peut faire une macro Pythagore, qui à un polygone, en fait un carré, colle les figures de la fractale de pythagore - l’angle étant une donnée de la figure.


Lancer la figure avec la macro non appliquée : https://huit.re/PythaFractaleBase
(sélectionner l’icone de macros-construction, entre la corbeille et la calculatrice, puis activer la macro personnelle PythaPoly qui demande seulement un polygone : vous cliquez sur les carrés rouges et bleus au fur et à mesure des constructions)

Même figure, même macro mais avec couleurs aléatoires : https://huit.re/PythaFractaleColor

On a choisi un curseur pour l’angle, c’est discutable car la figure aurait été plus en manipulation directe avec un point sur le demi cercle, mais finalement c’était moins pratique.

Détail sur les couleurs aléatoires

En fait tout est aléatoire, c’est-à-dire que pour chaque polygone (le triangle et les deux carrés), on tire au hasard R, G et B du RGB color, soit 9 expressions qui sont ensuite placées dans le setRGBColor de chaque polygone.

(fin du bloc)


La version Bockly

Cette activité, sur une problématique « collège » (même si, clairement, le code n’est pas « de collège » ;-) illustre à nouveau la pertinence de la récurrence dans cette modification de Blockly pour DGPad.

Voici le code que nous allons commenter

Tout d’abord, la partie « de calcul » est seulement dans les premières lignes : le calcul du sommet U du triangle GHU. La variable de la figure ang est le curseur qui pilote l’angle du sommet « de droite » du triangle GHU (en U en pratique) et la variable de la figure LePt est simplement le point (cos(ang), sin(ang)) construit dans la figure (on aurait pu mettre un ligne de plus de programme).

Comme on l’a vu avec le triangle de Sierpinsky, le triangle est tracé avec 4 points (G, H, U, G) pour être fermé et donc colorié (en réglant l’opacité).

La fonction AjouteCarre ajoute un carré orienté dont on reçoit deux sommets consécutifs (là encore 5 points pour fermer la figure) et renvoie les deux autres sommets du carré pour appliquer la récurrence.

La fonction générale fait deux appels récursifs pour chaque carré à construire. L’écriture est plutôt synthétique avec les listes.

Le programme principal applique la fonction générale aux deux points (déjà construit) D et C du triangle initial ABCD.

Manipuler la figure en ligne : https://huit.re/PythaFractaleBLK

Haut de la barre « Récursivité dans le Blockly de DGPad »

Intro PV | Philo et prise en main de DGPad | Aspects Dynamiques de la PV | Récursivité dans le Blockly de DGPad



Développements en cours et ultérieurs

On aura compris que cette présentation est celle qu’une première version de l’intégration de Blockly dans DGPad, celle sur les scripts de comportement.

Les développements en cours sont assez clairs :

La version « de scène », c’est-à-dire la mise en place des DGScripts. C’est cette version qui contient (déjà finalisé) les tortues 2D et 3D, dans une version dynamique - donc plus générale qu’une simple tortue logo comme GeoTortue. Les DGScripts comprendront aussi la création d’objets. C’est le chantier en cours de développement par Eric Hakenholz en ce moment.

Les variables globales : on a vu que le code est prêt à les recevoir, elles fonctionnent déjà dans certaines conditions, il s’agit surtout de finaliser l’environnement de ces variables globale.

On peut raisonnablement penser que quand ces deux points seront finalisés, les versions tablettes (Android et iOS) contiendront ces derniers développements, ce qui n’est pas le cas actuellement (début mai 2016).

Aperçu de la tortue DGPad (disponible depuis le 15 mai - éventuellement vider le cache de votre navigateur)

Vous remarquerez que la tortue est dans l’onglet d’un point. Le script est construit sur un point, il renvoie (et construit donc) une liste DGPad.

Les liens vers 4 vidéos de présentations ont été rajoutées en début d’article

Les développement ultérieurs

l’intégration Macros/scripts Blockly : la façon dont les macros sont programmées dans DGPad sont particulièrement compatibles avec l’écriture des blocs de Blockly. L’intégration devrait se faire facilement, et pourrait apporter l’anticipation des constructions dans les macros, ce qui n’est pas le cas pour le moment dans les macros de DGPad, contrairmeent à celles de CaRMetal.

• la question, importante, de l’environnement général sur les blocs est encore en réflexion : va-t-on s’orienter vers la mise à disposition de blocs standards dans le logiciel comme il y a des macros standards ? Y aura-t-il une exportation/importation de blocs ? ou seulement de macros comportant des scripts par blocs ? Ces questions sont encore ouvertes.

Prochain article

On peut raisonnablement penser que l’utilisation des DGScripts et des « tortues DGPad » sera abordée dans un des numéro 52 ou 53 de MathémaTICE, vers octobre prochain..

Téléchargement

L’article a été mis en ligne sans version PDF de l’article. Celui-ci devrait être ajouté vers la fin juin. Penser à revenir voir les nouveautés mis à jour dans cet article.

Les figures de cet article. Pour les utiliser, il faut donc se rendre sur http://dgpad.net/index.php et glisser les figures sur la page de DGPad.

Exemple de fiches pour une formation initiale (sans Blockly)

Autres documents autour de DGPad

Le site de l’auteur (dont vidéos) : www.dgpad.net

Le code de DGPad sur GitHub : https://github.com/dgpad/dgpad

Le fichier apk pour tablettes Android (utile à La Réunion par exemple où le Google Play n’est pas complet)

DGPad pour Android sur Google Play (pour le moment sans Blockly)

DGPad pour iOS

Didacticiel et activités collège de l’IREM de Toulouse : http://www.mg-maths.net/DGPadDidacticiel/index.html

Forum commun DGPad et CaRMetal (maintenu par Patrice Debrabant) : http://carmetal.org/forum/