Marche aléatoire

Lorsque la situation des marches a été expérimentée avec les participant·es de la recherche-formation, le chercheur-formateur (moi-même) a donné accès à la mise en situation ainsi qu’à Scratch.

Florence et Déborah (pseudonymes) ont travaillé en équipe, mais elles ont rapidement constaté qu’elles avaient des manières différentes de travailler. Florence avait besoin de résoudre cette tâche à l’aide de l’approche théorique.  Elle a alors fait un diagramme en arbre et a constaté qu’il faut obtenir deux fois pile et deux fois face (sans tenir compte de l’ordre) pour revenir au point de départ après quatre lancers de pièce de monnaie. Florence a alors dénombré 6 cas favorables sur 16 cas possibles, pour une probabilité de \(\frac{6}{16}\). De son côté, Déborah préférait se faire un plan de programmation pour pouvoir se lancer dans Scratch. Il n’est toutefois pas facile de faire ce plan, car des bases en programmation sont requises pour savoir ce dont on a besoin pour faire ce plan. Pour Déborah, il était nécessaire de voir d’abord les options de blocs avant de commencer le programme.  Elle a alors consulté un document avec tous les blocs possibles dans Scratch pour repérer les blocs dont elle pourrait avoir besoin. Florence disait plutôt ne pas avoir besoin de plan et préférait y aller à tâtons dans Scratch, après avoir déterminé la probabilité théorique. Ensuite, pour simuler le déplacement en générant le résultat d’une pièce de monnaie, Florence a hésité sur la façon de générer un résultat de pièce de monnaie, puis en est venue à la conclusion qu’il fallait choisir un nombre entier aléatoire entre 1 et 2. Pour chacun des deux nombres possibles, elle a attribué l’action d’avancer (pile) ou de reculer (face).

Après avoir conçu un programme qui permet au personnage de se déplacer quatre fois à l’aide d’une boucle, puis de vérifier s’il revient au point de départ (si le nombre de pile est égal au nombre de face), Déborah voulait faire calculer la fréquence basée sur les résultats expérimentés. Lorsqu’elles y sont parvenues, Déborah et Florence étaient d’avis qu’elles se sont bien complétées, en ne travaillant pas de la même façon : Déborah préférait commencer son programme globalement pour ensuite préciser les détails qui se trouvent à l’intérieur, alors que Florence préférait commencer sur des parties en détail, puis d’élargir en ajoutant des couches au programme.

Grace et Émilie ont formé une autre équipe et ont commencé par établir un plan de programmation pour identifier les variables nécessaires et la structure générale du programme. Pour générer le résultat d’une pièce de monnaie, Grace et Émilie ont été un peu bloquées. Le chercheur a alors précisé que la seule façon d’avoir du hasard dans Scratch est d’utiliser le bloc de nombre aléatoire. Grace a alors pu générer un nombre aléatoire entre 1 (pile) et 2 (face). Elles ont créé une variable pour compter le nombre de pile, puis une autre variable qui dénombre le nombre de face, mais cette fois dans les nombres négatifs. Ainsi, elles ont additionné les résultats de ces variables et Émilie a expliqué que le programme vérifie si cette somme est égale à zéro pour savoir si le personnage revient au point de départ. C’est donc l’idée d’avancer (+1 pour pile) et de reculer (-1 pour face). Grace a précisé que cela revient à voir le déplacement du personnage sur une droite numérique. En s’appuyant seulement sur les valeurs des variables (sans faire déplacer le personnage), Émilie a testé le fonctionnement de leur programme : elle a obtenu 3 résultats favorables sur 10 essais, alors la fréquence observée était de \(\frac{3}{10}\). Elles ont ensuite testé 10 échantillons de 100 essais en notant les fréquences, avec l’aide du chercheur-formateur pour garder une trace des résultats des simulations dans une liste. Grace a remarqué que les fréquences étaient d’environ 0,4. Émilie a complété un diagramme en arbre et a obtenu elle aussi une probabilité de \(\frac{6}{16}\)=0,375, ce qui leur a permis de comparer la probabilité théorique aux fréquences observées. En simulant le programme plusieurs fois, les résultats s’ajoutaient chaque fois dans la liste et Émilie a fait remarquer que ces fréquences sont assez près de la probabilité théorique. Grace et Émilie ont ensuite calculé la moyenne de leurs essais répertoriés dans la liste, soit la moyenne des fréquences obtenues, qui devrait normalement être une estimation encore plus fiable de la probabilité, en raison de la Loi des grands nombres.

Si on compare ce qui a été fait par ces deux équipes, on constate des différences entre les programmes. Par exemple, pour vérifier si le personnage revient au point de départ, Florence et Déborah ont vérifié si les variables du nombre de pile et du nombre de face sont égales, ce qui est différent (mais équivalent) à vérifier si la somme est nulle avec des nombres positifs et négatifs, comme l’ont fait Grace et Émilie. On pouvait même utiliser une seule variable, comme Brian l’a fait, en ajoutant 1 lorsqu’on obtient 1 (pile) et en enlevant 1 lorsqu’on obtient 2 (face), puis en vérifiant si la valeur finale est égale à zéro après quatre déplacements. Une autre différence concerne l’aspect visuel : pour le programme de Florence et Déborah, ainsi que celui de Christian, le personnage effectuait les déplacements tels qu’expliqués dans la mise en situation.  Quant au programme de Grace et Émilie, il effectuait simplement les calculs à partir des variables, sans représenter les déplacements, ce qui permettait d’effectuer des simulations plus rapidement, en se détachant de chaque lancer individuel de pièce de monnaie.

Il existe donc une multitude de façons différentes d’écrire un programme (et donc une multitude de solutions au problème), selon le choix des variables, les vérifications des conditions et le niveau de flexibilité qui est accordée à l’utilisateur du programme qui est produit. Il faut donc penser à plusieurs aspects en même temps pour que le programme fonctionne et il est possible d’avoir une approche plus globale ou par parties, ce qui amène des allers-retours pour lesquels il faut constamment s’ajuster. Il faut aussi être inventif pour trouver une façon de générer l’équivalent d’un choix (pile ou face) à l’aide d’un bloc de nombres aléatoires. En concevant un simulateur, il semble y avoir une réelle appropriation des possibilités du simulateur et des prolongements pourraient être expérimentés aussitôt.

Il a d’ailleurs été question des prolongements possibles pour cette situation, de manière à la complexifier. En voici quelques suggestions:

1. Le nombre de lancers pourrait être modifié (six lancers au lieu de quatre ou encore généraliser à n lancers) ; 
2. Une troisième option (par rapport à avancer ou reculer) pourrait être de rester sur place ; 
3. On pourrait considérer quatre options (haut, bas, gauche ou droite), ce qui amènerait à se déplacer sur le plan dans les quatre directions ; 
4. On pourrait plutôt s’intéresser au nombre de déplacements nécessaires pour revenir au point de départ. Selon le prolongement, il s’agit parfois d’un simple ajustement dans le programme. Par exemple, pour le nombre de déplacements, il est facile de modifier la boucle afin qu’elle se répète six fois au lieu de quatre. Pour d’autres prolongements, cela demanderait davantage d’ajustements.

Pour le troisième prolongement, voici un exemple de programme qui simule une marche aléatoire dans les quatre directions. On reconnaît la structure du programme, mais le problème devient tout de même assez différent.

En ce qui concerne le quatrième prolongement, ce simulateur calcule la moyenne de la longueur des déplacements nécessaires afin de revenir au point de départ, dans une marche aléatoire simple (avancer et reculer).  Il est à noter que le personnage peut parfois se déplacer pendant très longtemps, alors il est préférable d’aller « voir à l’intérieur » et d’enclencher le mode turbo pour que cela s’exécute en moins d’une seconde. Pour résoudre ce problème théoriquement, il faudrait effectuer des calculs de sommes infinies, ce qui serait très complexe, alors on peut plutôt regarder ce qui se passe en pratique avec un tel simulateur. On constate avec surprise que les résultats obtenus des longueurs de déplacements ne semblent pas converger : 7044, 7345, 64, 200, 23 604, 40… Il est à noter que la simulation est parfois longue lorsque le personnage se rend très loin du point de départ, car cela lui prend beaucoup de déplacements pour revenir.