Pour illustrer ce phénomène, nous allons commencer par faire dessiner à la tortue Python un triangle équilatéral.
Nous utilisons le module turtle en mode console avec Python 3.5 [3] . Ainsi chacun pourra constater les effets en testant dans son environnement.
Sans entrer dans les détails de la programmation orientée objet, j’apporte quelques précisions :

• Le choix suivant a été fait : importer le module turtle entier sans alias et sans importer les fonctions et classes du module.
• De ce fait chaque appel à une fonction du module doit être préfixé par « turtle. ». L’appel d’une méthode de classe (fonction propre à une classe d’objet) se fait en préfixant par le nom de l’objet.

Ces choix sont motivés non pas par une transposition facilitée à une activité à faire avec les élèves, mais pour permettre au lecteur d’avoir une meilleure compréhension des éléments manipulés par le programmeur.

Nous voilà avec une aire de jeux prête à accueillir la tortue. Donnons lui une existence.

Une flèche représentant la tortue « caroline [4] » apparaît au centre de la fenêtre.

Après lui avoir demandé d’exécuter les mouvements ci-dessus, on obtient la fenêtre suivante :

Figure 1

La tortue a dessiné un triangle équilatéral.

L’utilisateur expert en fenêtres que nous sommes ne peut s’empêcher de modifier la taille de la fenêtre. Par exemple, l’observateur peut obtenir en modifiant à la souris :

Figure 2

La taille de la fenêtre a été modifiée. Le dessin reste identique.

Le dessin n’est pas modifié et « caroline » se trouve toujours au centre de la fenêtre.
Analysons l’effet de la fonction setworldcoordinates. Cette fonction prend quatre arguments.
Les deux premiers représentent les coordonnées dans le nouveau repère du coin inférieur gauche de la fenêtre. Les deux derniers représentent les coordonnées dans le nouveau repère du coin supérieur droit de la fenêtre.

L’effet de la fonction dépend de la forme (dimensions) de la fenêtre au moment de son exécution.
En ce sens le changement de repérage induit des changements que le programmeur [5] ne peut prévoir.
On commence par rétablir les dimensions initiales de la fenêtre, puis on change le système de coordonnées.

On peut voir [6] déjà l’effet du changement de repère. Pour se convaincre, on demande à « caroline » de refaire le dessin depuis le départ.

Figure 3

La fenêtre a été modifiée. Le dessin du triangle équilatéral semble curieux.

À la question : « Quelle est la nature du triangle ? », je doute que l’on réponde de but en blanc « équilatéral ». Pourtant c’est bien un triangle équilatéral qui a été tracé. « caroline » en est convaincue car le changement de coordonnées n’a pas d’effet sur elle, mais sur l’observateur extérieur. Ce que « caroline » perçoit est juste un changement de forme de son aire de jeux qui devient un carré de 400 unités de large.
Pour l’utilisateur standard, la taille de la fenêtre reste identique et est un rectangle de 480 pixels de large pour 320 pixels de haut. Les résultats des deux commandes ci-après en témoignent.

L’avertissement du document d’aide est donc justifié et le changement de taille de fenêtre par l’utilisateur standard a des effets difficiles à anticiper pour le programmeur.
En effet le changement simple de dimensions de la fenêtre de manière graphique ou à l’aide d’une ligne de commande ne réduit pas l’écart de perception entre « caroline » et nous.

La commande ci-dessus produit ceci :

Figure 4

La fenêtre de forme carrée [1].

[1] On note l’apparition des ascenseurs.

Il faut de nouveau invoquer la commande suivante :

pour rétablir une perception conforme [7] du monde dans lequel vit « caroline ».

Figure 5

Fenêtre de forme carrée, jeu de coordonnées modifié.

Comme nous l’avons vu précédemment, les changements d’angles ne sont que des changements de perception des angles par l’observateur de la fenêtre. Les angles n’ont pas changé dans le monde où vit « caroline ».
Dans cet exemple quelles sont les mesures des angles perçus par l’observateur de la fenêtre ?
Tout d’abord intéressons nous au changement de repère. La fonction setworldcoordinates induit le changement de repère suivant décrit par les changements de coordonnées de deux [8] points. Ainsi les images des coins inférieur gauche et supérieur droit suffisent à déterminer l’application affine de changement de repère.
Appelons A le coin inférieur gauche et B le coin supérieur droit.
Nous proposons les commandes [9] suivantes :

La fenêtre a une largeur de 480 pixels et une hauteur de 320 pixels. L’origine du repère est par défaut au centre de la fenêtre [10] .

Cela donne pour les coordonnées dans le repère initial :

$$\text{A}\left(\begin{array}{c}-240\\-160\end{array}\right)\text{ et }\text{B}\left(\begin{array}{c}240\\160\end{array}\right).$$

Le changement de repère a eu lieu. L’observateur perçoit un changement de position de « caroline ». On rappelle qu’aucune commande de déplacement ne lui a été transmise.
Cela donne pour les coordonnées dans le nouveau repère :

$$\text{A’}\left(\begin{array}{c}-100\\-150\end{array}\right)\text{ et }\text{B’}\left(\begin{array}{c}300\\250\end{array}\right).$$

Le centre [11] de la fenêtre dans ce nouveau repère est placé en $\text{O’}\left(\begin{array}{c}\frac{-100+300}{2}\\\frac{-150+250}{2}\end{array}\right)$.

Pour s’en convaincre demandons à caroline de rejoindre ce point :

Demandons lui de dessiner un carré :

Le résultat peut paraître décevant pour l’observateur. « caroline » a quant à elle toutes les raisons d’être satisfaite. Elle a bel et bien tracé un carré.

Figure 6

Le carré de « caroline ».

Précisons la matrice associée au changement de repère. Il correspond à la matrice composée des vecteurs de la nouvelle base de l’espace vectoriel sous jacent dans les coordonnées relatives à l’ancienne base.
Notons $f$ l’application affine de changement de repère, $\vec{f}$ l’application linéaire associée.

On a :

$$\overrightarrow{f(\text{A})f(\text{B})}=\vec{f}(\overrightarrow{\text{A}\text{B}})$$

$$ \left( \begin{array}{c} 400\\ 400 \end{array} \right) = \left( \begin{array}{cc} m_{11}&0\\ 0&m_{22} \end{array} \right) \left( \begin{array}{c} 480\\ 320 \end{array} \right) $$

Ce qui donne, dans notre cas la matrice de changement de base : $\left( \begin{array}{cc} \frac{5}{6}&0\\ 0&\frac{5}{4} \end{array} \right)$

Les nouvelles coordonnées $(x’,y’)$ d’un point noté M d’anciennes coordonnées $(x,y)$ sont données ainsi :

$$ \left( \begin{array}{c} x’\\ y’ \end{array} \right) = \left( \begin{array}{cc} \frac{5}{6}&0\\ 0&\frac{5}{4} \end{array} \right) \left( \begin{array}{c} x\\ y \end{array} \right) +\left( \begin{array}{c} 100\\ 50 \end{array} \right) $$

Le passage des nouvelles coordonnées aux anciennes est aisé :

$$ \left( \begin{array}{c} x\\ y \end{array} \right) = \left( \begin{array}{cc} \frac{6}{5}&0\\ 0&\frac{4}{5} \end{array} \right) \left( \begin{array}{c} x’\\ y’ \end{array} \right) -\left( \begin{array}{c} 120\\ 40 \end{array} \right) $$

Les coordonnées des sommets du carré tracé par caroline sont : $(100 ;50)$, $(200 ;50)$, $(200 ;250)$, $(100 ;250)$.

Si on cherche les anciennes coordonnées des sommets du carré (celles perçues par l’observateur), on obtient :

$(0 ;0)$, $(120 ;0)$, $(120 ;80)$, $(120 ;80)$.

Il devient clair que l’observateur ne perçoit pas un carré. Il perçoit un rectangle de 120 pixels de large par 80 pixels de haut.

Si nous voulons que caroline dessine un carré selon l’observateur, nous pouvons le faire. Il suffit de lui transmettre les coordonnées des sommets dans son repère.

Prenons un carré de centre le centre de la fenêtre et de longueur de côté 48 [12]. Les coordonnées pour l’observateur sont $(-24 ;-24)$, $(24 ;-24)$, $(24 ;24)$, $(24 ;-24)$.

Les coordonnées à transmettre à caroline seront : $(80 ;20)$, $(120 ;20)$, $(120 ;80)$, $(80 ;80)$.

Figure 7

Un carré pour l’observateur...

L’observateur est satisfait, mais « caroline » connaît la vérité sur la figure qu’elle vient de tracer : ce n’est pas un carré.

Revenons désormais au problème initial. Comment sont perçus les angles du triangle équilatéral du monde de « caroline » par l’observateur ?

On considère les trois sommets R, S et T du triangle. Exprimons leurs coordonnées dans le repère de « caroline » :

R$(100 ;50)$, S$(200 ;50)$, T$(150 ;50+50\sqrt{3})$.

donne le même résultat que :

Les coordonnées perçues par l’observateur sont :

R$\left(0 ;0\right)$, S$\left(120 ;0\right)$, T$\left(60 ;40+40\sqrt{3}\right)$.

Les coordonnées de $\overrightarrow{\text{RS}}\left(120 ;0\right)$ et $\overrightarrow{\text{RT}}\left(60 ;40+40\sqrt{3}\right)$

Le calcul de l’angle $\widehat{\text{SRT}}$ se fait à l’aide d’un arccosinus :

$$\widehat{\text{SRT}}=\arccos\left(\dfrac{\overrightarrow{\text{RS}}\cdot\overrightarrow{\text{RT}}}{\Vert\overrightarrow{\text{RS}}\Vert\times\Vert\overrightarrow{\text{RT}}\Vert}\right) $$

On trouve après calcul [13] : $\widehat{\text{SRT}}\approx 49,1^{\circ}$.

Ce phénomène n’est pas lié spécifiquement à Python ou encore au module turtle, mais plutôt à une adaptation plus ou moins automatique à la fenêtre de vue de l’observateur. Cette sorte d’autozoom peut s’avérer surprenant dans certains cas, inattendu dans d’autres :

Voici un exemple [14] traité avec GeoGebra [15].

Figure 8

Figure GeoGebra (vue standard)

Après un clic droit et « Recadrer », on obtient :

Figure 9

Figure GeoGebra (vue recadrée)

Les outils de mesures confirment la nature des objets :

Figure 10

Figure GeoGebra avec mesures (vue recadrée)

Ce n’est pas un défaut de GeoGebra qui serait pointé ici, mais plutôt l’illustration d’une fonctionnalité utile pour la représentation des fonctions, mais pouvant gêner l’observateur dans une activité de géométrie euclidienne.

Revenons donc au problème évoqué par François Goichot dans son article (Python et les graphes de fonctions). À savoir la représentation d’une fonction et le changement de repère permettant une meilleure visualisation du graphique. La fonctionnalité recadrer peut être un atout ici.

Voici deux illustrations d’une vue d’un graphique de fonction :

La présence du repère est d’une aide précieuse [16] pour l’observateur. La différence de conception de GeoGebra et du module turtle de Python apparaît plus nettement. L’observateur agit directement sur la vue et le repère dans ce logiciel.

Cette fonctionnalité est déjà présente depuis de nombreuses années dans les calculatrices graphiques. On veut représenter graphiquement la fonction $x\longmapsto 2x^{2}-3x+1$. Cette fois-ci, l’observateur ne peut pas modifier [17] la taille de la fenêtre d’affichage.

Pour illustrer, j’utilise le simulateur en ligne de la Numworks [18].

Ce qui diffère entre les trois vues est le repère. Ce changement de repère s’effectue avec des commandes analogues à celles de setworldcoordinates présentée plus tôt. Le fait que les axes du repère s’affichent à l’écran, ce dernier restant de taille fixe, permet à l’utilisateur de comprendre qu’un changement de repère a eu lieu et de l’appréhender correctement.

Des cas plus extrêmes ne permettent pas non plus l’affichage immédiat du repère ou de la fonction, mais sortent du cadre de la comparaison avec les outils précédents dont le module turtle de Python.

Voici deux exemples que j’emprunte à Benjamin. Dans ces exemples un affichage d’un graphique compréhensible nécessite un travail d’analyse mathématique. La question du contrôle a priori des résultats d’un logiciel ou procédé technologique se pose donc pleinement et les mathématiques ont ici toute leur place et validité.

$$x\longmapsto 100(x-20)^{2}-100$$

$$x\longmapsto \sqrt{(x-20)}$$

Scratch et GeoTortue

Scratch [19] propose une interface graphique ou espace de déplacement fixe avec un repère fixe. Il consiste en une scène de 480 pixels de large et de 320 pixels de haut munie d’un repère orthonormé centré.

De fait, Il n’y a pas de changements perceptifs possibles. L’utilisateur, la scène et le lutin « vivent » dans le même environnement.

De même avec GéoTortue [20], dans un usage classique, on retrouve quelque chose d’analogue avec la différence que l’espace graphique peut être modifié à partir des préférences. Cette modification n’a pas d’incidence sur le système de coordonnées utilisé par la tortue et la perception de ce dernier par l’observateur.

DGpad

Suite à des discussions avec des membres du comité de rédaction, ainsi que des expérimentations personnelles, j’ai voulu faire également un détour vers DGpad [21].

Ce logiciel est intéressant à plus d’un titre [22].

Ce qui m’intéresse ici c’est le changement perceptif entre le logiciel et l’utilisateur. En particulier le module Blockly intégré permet la programmation d’une tortue (animal décidément très cher à nos yeux).

Le choix de conception est le suivant : restreindre les possibilités de vision de l’observateur à la vision classique de géométrie euclidienne (le repère reste orthonormé). À la différence de GeoGebra il n’y a pas de changement perceptif induit par un autozoom sur les objets créés.

A priori il n’y a pas de raisons particulières pour voir des déformations d’angles comme observées dans la partie Analyse dans le module turtle. C’est ce qu’on constate.

En revanche il y a d’autres changements perceptifs en jeu qu’il me semble important d’évoquer.

La perception du temps

Dans le module blockly de DGpad, la perception du temps n’existe quasiment pas pour l’observateur. La tortue DGpad réalise de manière instantanée (pour l’observateur) les tracés de figures programmés. Cette non-perception du temps et donc du déroulement des séquences d’instructions est une référence didactique à prendre en compte pour élaborer des scénarii pédagogiques utilisant la programmation visuelle de DGpad (Blockly/Tortue).

Figure 11

Une spirale réalisée avec une tortue attachée au point P1

Dans la figure ci-dessus l’exécution du script Blockly se fait de manière quasi instantanée. L’observateur ne peut percevoir le déroulement des séquences d’instructions. Seule l’analyse combinée du script et de la figure obtenue permet de comprendre les enchaînements d’instructions.

Concurrence des unités

L’effet zoom (accessible depuis la molette sur ordinateur ou par un pincement sur tablette) induit un changement perceptif attendu et non problématique, à savoir un effet sur la perception des objets.

Comme le repère (plus précisément le système de coordonnées) reste orthonormé, on n’observe pas de déformation des angles lors de cette action, mais seulement un agrandissement ou réduction des longueurs.

Par contre si les objets sont obtenus comme résultat d’un algorithme de tracé du module Blockly/Tortue, on observe des phénomènes particuliers liés au choix des unités de longueur.
Voici un exemple que chacun peut manipuler [23].

Vue du script Blockly/Tortue dans DGpad

Réalisation de trois triangles équilatéraux avec la tortue. Deux unités de longueur différentes sont utilisées.

Pour ce qui est de l’utilisation du module turtle la fonction setworldcoordinates provoque des effets sur le graphique qui peuvent être mal compris et mal appréhendés. Des logiciels grapheurs tels que GeoGebra ou le tracé de graphique par une calculatrice scientifique présentent la même fonctionnalité pour l’utilisateur d’adapter la vue à la fenêtre d’affichage. La différence se fait sur la perception de l’observateur. Pour les deux derniers, une possibilité d’accéder facilement au repère courant est un avantage que l’observateur habitué peut trouver normal, mais qui n’est plus automatique dès qu’on utilise des systèmes où beaucoup d’éléments sont à fournir. Dans le cas du module turtle, le repère est un élément dont il faudrait avoir une méthode de construction pour l’utiliser de manière plus sereine.

Une alternative à l’utilisation de la fonction setworldcoordinates serait d’effectuer le changement de coordonnées dans le programme principal pour un affichage correct (en s’assurant de garder un repère orthonormé par exemple pour la partie géométrie euclidienne, adaptée aux données pour la représentation graphique de fonctions). Le développement d’un tel outil complique énormément la programmation du tracé d’une représentation graphique d’une fonction et n’impacte pas sensiblement sa représentation, pas plus que la perception de l’observateur.

Il paraît donc plus utile de développer une fonction traçant le repère à l’aide du module turtle [24].

Ces remarques semblent dépasser les compétences visées par les programmes de mathématiques en terme algorithmique et programmation. Par contre je pense qu’il est commun de rencontrer ce type de situations et même d’autres effets parfois inattendus. Dans ce cas une bonne appréhension du problème lié à l’affichage et à la perception de cet affichage ainsi qu’une sensibilisation sur l’analyse a priori des outils numériques utilisés seront utiles aux enseignants.