Mathématice, intégration des Tice dans l'enseignement des mathématiques  
Sommaire > N°21 - Septembre 2010 > Un an d’algorithmique avec CaRMetal en (...)

Un an d’algorithmique avec CaRMetal en Seconde
Moteur de recherche
Mis en ligne le 2 août 2010, par Alain Busser

Cet article est une réponse à l’appel à contributions n°1

Raisonner algorithmiquement, c’est raisonner en séquence, chose qui est difficile pour la plupart des élèves de Seconde. Une longue insistance peut mener à certains succès mais il faut être patient, ou connaître un outil miraculeux...

Enregistrer au format PDF

Rappel du programme d’algorithmique

Trois chapitres apparaissent dans le programme (de Seconde mais sous le titre "objectifs pour le lycée") :

  • Entrées, sorties, affectation de variables
  • Boucles à nombre prédéfini d’exécutions
  • Tests et boucles à condition de sortie

Une idée qui m’avait paru simple était de consacrer un trimestre à chacun de ces chapitres, en déplaçant toutefois les tests au second trimestre pour équilibrer.

Rétrospectivement l’ampleur des difficultés me donne envie de ne pas traiter du tout les boucles à condition de sortie (dans le contexte des suites, numériques ou non, ces boucles semblent plus pertinentes en Première), et de passer plus de temps sur les affectations successives de variables, cette étape indispensable pour la suite requérrant plus de temps pour être assimilée par les élèves. Pour 2010-2011 je penserais donc à quelque chose comme ça :

  1. er trimestre : Entrées et sorties de programmes, basées sur le vocabulaire des fonctions (les entrées étant appelées antécédents et les sorties, images) ; notion d’affectation. Problèmes d’affectations successives.
  2. e trimestre : Notion de tests, en relation avec des fonctions affines par morceaux (comme celle qui donne l’impôt en fonction du revenu). Martellage des problèmes d’affectations successives.
  3. e trimestre : Boucles "de .. jusqu’à ..". Notion d’indice de la boucle, applications à des calculs de moyenne, éventuellement (avec des tableaux triés) de quantiles.

On constate que je n’ai donc pas l’intention de parler de boucles "tant que" du tout en Seconde...

L’enseignement basé sur la problématique, appliqué à l’algorithmique, favorise l’idée de faire des TP avant le cours (qu’on n’est d’ailleurs pas censé faire du tout) d’algorithmique, j’ai d’emblée fait le choix de faire faire de la programmation à mes élèves plutôt que leur confier un pensum sur des outils spécifiquement consacrés à l’algorithmique sans programmation (style Execalgo, AlgoBox ou LARP). Une contrainte temporelle s’est alors opposée à mon enthousiasme débordant d’octets : Comment caser une dizaine de TP dans l’année scolaire, et en plus avoir le temps de familiariser mes élèves à l’outil que j’allais choisir ? D’autres contraintes temporelles s’y sont d’ailleurs ajoutées : Refus obstiné (de ma part) d’abandonner l’enseignement de la géométrie, et participation par mes élèves à deux ateliers de l’IREM de la Réunion (celui sur les nomogrammes et celui dont il est question ici, sur l’algorithmique). Le meilleur moyen de satisfaire toutes ces contraintes temporelles est celui qui consiste

  1. à faire plusieurs de ces choses en même temps (par exemple, géométrie et algorithmique)
  2. à ne pas "perdre" de temps sur la formation des élèves à l’outil, l’idéal étant de travailler sur un outil qu’ils connaissent déjà (tableur ?)

Pour le mélange géométrie+algorithmique, j’ai repéré (c’est le cas de le dire !) 3 outils sur lesquels on peut trouver des ressources, dans les manuels, le doc d’accompagnement ou sur des sites tels celui-ci :

  • Python, avec le module "tortue". Choix d’emblée écarté parce que si on demande à Python d’afficher "4/5", il affiche 0 [1], et parce que la tortue, héritée de LOGO, emporte sur sa carapace un repère mobile, hors sujet en Seconde ;
  • Scratch, conçu par des chercheurs du MIT pour des enfants. Malgré l’existence de succès en Seconde avec Scratch (par exemple, cette expérience réunionnaise), j’ai abandonné ce logiciel parce que là encore, on évolue dans un repère mobile, et que Scratch, "orienté calcul parallèle", me semble peu approprié pour l’algorithmique. Pour autant les arguments que j’ai entendus pour justifier le refus de Scratch par des collègues ("c’est moche", "les couleurs sont trop criantes", "c’est pour les enfants, par pour les ados", "c’est pas sérieux", "on fait des maths, pas du rap !", "ça n’a pas la cote") m’ont toujours paru effarants !
  • CaRMetal, logiciel de géométrie dynamique muni d’une console JavaScript, qui de surcroît permet de programmer facilement par clics de la souris dans un menu. C’est donc cet outil que j’ai choisi.

Programmer sans le clavier

Dans la plupart des langages de programmation, l’instruction d’affichage d’une variable s’écrit Print. Programmer, c’est donc avoir souvent à écrire ces 5 lettres. Pour faire gagner du temps au programmeur, on utilise des raccourcis clavier (Shift+P ou Ctrl+P par exemple pour avoir le mot "print" d’un coup). Ce confort du programmeur devient une nécessité quand on programme sur une calculatrice ou un téléphone portable, dont le clavier possède trop peu de touches pour écrire toutes les lettres.

  • Dans les calculatrices graphiques type "Ti 82 Stats", l’élève programme en cherchant les instructions dans des menus. L’idée est excellente mais par expérience, se rappeler où naviguer est difficile (le "Print" par exemple se trouve très logiquement dans "E/S" puisque c’est une entrée/sortie, mais "E/S" se trouve dans le menu "Prog" qui est justement celui qu’on a dû explorer pour commencer à taper le programme ; et le symbole d’égalité lui, ne se trouve pas dans "Prog" mais dans "tests". Il est possible de programmer avec des Ti 82 Stats mais difficile, et le prof a tout intérêt à faire une répétition la veille (et à utiliser le TBI le jour même).
  • Dans AlgoBox, on clique sur des instructions pour les sélectionner [2]. Ce qui fait apparaître une boîte de dialogue (par exemple, pour une boucle, on entre le nom de l’indice, sa valeur initiale et sa valeur finale). On peut donc dire que dans AlgoBox, programmer consiste à se procurer des briques toutes faites, les adapter à son problème, et les assembler. Toutefois les boîtes de dialogue sont modales ce qui signifie qu’elles cachent le programme en cours de fabrication. Or ceci peut amener l’élève à une situation blocante (par exemple, lorsqu’il veut entrer une boucle alors qu’il n’avait pas encore créé de variable pour l’indice de cette boucle) qui est à éviter en TP, surtout lorsque le prof s’affole facilement (qui connaît un prof multitâche ? Débloquer un élève c’est possible mais il ne faut surtout pas qu’un deuxième blocage survienne pendant ce temps !)
  • Dans Scratch, les briques sont visibles dans une trousse d’outils à gauche de l’écran, et on les tire avec la souris sur le plan de travail (au centre de l’écran), lequel est d’ailleurs visible en même temps que l’affichage du programme (à droite de l’écran) : Les fenêtres de Scratch ne sont pas modales, au point d’ailleurs qu’on n’a même pas conscience qu’il y a plusieurs fenêtres.
  • Ce qui m’a fait choisir CaRMetal, c’est qu’en plus de cette philosophie du "programmer en cliquant", les briques ont déjà tout ce qu’il faut pour fonctionner : Au lieu d’avoir à remplir un motif, l’élève a un bout de programme sous les yeux, qu’il n’a plus qu’à adapter à ses besoins. Autrement dit, avec CaRMetal, l’élève n’a pas à créer mais à modifier de l’existant. La création se situe alors entièrement au niveau du choix de l’outil. Cette facilité de programmer avec CaRMetal est d’ailleurs nécessaire, le langage JavaScript choisi par son créateur [3] n’étant pas vraiment le langage de programmation le plus simple qui soit...

Deux autres avantages de CaRMetal :

  1. Le temps nécessaire pour former les élèves à l’outil est nul ; mes collègues ayant fait le choix de GeoGebra ont passé une ou deux heures pour initier leurs élèves à GeoGebra, et n’arrivent même pas à imaginer que j’aie pu économiser ces deux heures (mes élèves ont-ils utilisé CaRMetal au collège ? Les ai-je formés à CaRMetal en dehors des cours ?)
  2. Le même outil m’a servi pour l’unique activité de l’année en géométrie dynamique (introduction aux vecteurs) et la géométrie dans l’espace (ces exercices)

Les TP présentés ci-dessous dans les différents onglets seront donc des CaRScripts (néologisme pour décrire JavaScript sous CaRMetal ; il y a douze TP mais ils sont numérotés jusqu’à treize en raison de l’existence d’un TP sur les vecteurs, sans algorithmique).

TP 1

Pour commencer, les affectations successives d’une même variable, ça s’appelle démarrer sur des chapeaux de roues ! Au cours de l’année, cette notion de x qui est égal à 2 mais pas tout le temps, a été la plus difficile de l’année, et s’est avérée blocante pour la théorisation des boucles.

Pour parer cette difficulté (le nom x désigne une variable, qui a donc vocation de ... varier, mais pas son contenu ; ainsi lorsqu’on écrit "x=2" ce n’est pas x qui est égal à 2 mais la variable de nom x) deux recettes me sont apparues dans l’année :

  1. Insister, répéter, recommencer, insister sur le long terme : En bref toute l’année scolaire a été ponctuée de "programmes de calculs" où des variables varient dans tous les sens [4] et si la moitié de la classe réussissait des exercices simples de ce genre lors du premier contrôle, pratiquement tous maîtrisaient (enfin !) la notion de variables qui changent en fin d’année scolaire (ils trouvaient la question si simple qu’ils en venaient à se demander où était le piège).
  2. Utiliser plusieurs variables. Par exemple alors qu’au début de l’année scolaire, trouver la valeur finale de x dans

$$x \leftarrow 2$$

$$x \leftarrow x+1$$

$$ x \leftarrow x^2$$

est difficile, alors que trouver la valeur finale de z dans

$$x \leftarrow 2$$

$$y \leftarrow x+1$$

$$ z \leftarrow y^2$$

l’est beaucoup moins.

Cependant lorsqu’on parcourt une boucle, c’est bien la valeur de l’indice qui change, et à moins d’utiliser un tableau (hors programme) on ne peut pas échapper éternellement (en boucle ?) au besoin d’affronter cette difficulté.

En fait il semble qu’il existe un autre moyen de contourner cette difficulté : Le mode pas-à-pas de l’outil de programmation. Mais CaRMetal n’en possède pas [5], et là-dessus l’avantage revient à Python et AlgoBox...

Ce TP est décrit (avec son énoncé) ici

TP 2

Dans le cours, dès le début de l’année, j’avais montré les "variables booléennes" sous formes de "fonctions JavaScript". Par exemple, pour savoir si un nombre x est entier naturel, j’avais proposé ceci, qui a eu beaucoup de succès auprès des élèves :

function estEntier(x){
   return(x == Math.round(x));
}
function estEntierNaturel(x){
   return(estEntier(x) && (x>=0));
}

Il a donc fallu après ça que j’explique pourquoi le même mot "fonction" est utilisé dans le cours de maths et en JavaScript (dans les deux cas, on fournit un nombre - l’antécédent - et on en obtient un autre -l’image- sauf que ci-dessus c’est un booléen qu’on obtient et pas un nombre ; l’idée qu’une fonction puisse être autre chose que numérique a été surprenamment facile pour les élèves, ce qui laisse augurer de beaux jours à mes collègues qui devront leur enseigner les suites).

Ce TP demandait aux élèves de programmer deux fonctions en JavaScript, l’une à une variable $R \mapsto \frac{4}{3}\pi R^3$, et l’autre à deux variables $(r,h) \mapsto \frac{\pi r^2 h}{3}$.

Bien qu’il n’y ait pas réellement d’algorithme (où est le problème que résoudrait l’algorithme ?) ce TP a présenté l’immense intérêt de mettre les élèves en situation sur le concept quelque peu abstrait de fonctions. Il se prête assez facilement à un changement de cadre (faire le même TP sous AlgoBox, Python, Scratch, la calculatrice, pourquoi pas tout ça ?) et prépare assez bien l’idée de refaire tout ça avec une boucle pour avoir un tableau de valeurs. Ou un nuage de points évoquant la représentation graphique, mais dans ce dernier cas, CaRMetal commence à devenir avantageux de par ses possibilités graphiques.

L’énoncé du TP est ici et une activité sur les nuages de points ici

TP 3

Découverte des boucles

Les boucles se rédigent de façon assez compliquée en JavaScript, par exemple si l’indice i doit aller de 1 à 10, on doit écrire quelque chose comme ceci :

for(i=1;i<=10;i+=1){
   ....
}

Cependant il est plus facile de généraliser à d’autres types de boucles. Par exemple si x (une abscisse) va de -2 à 2 par pas de 0,1, on peut faire varier directement x dans cette boucle :

for(x=-2;x<=2;x+=0.1){
   ....
}

Alors qu’avec AlgoBox, l’indice i est nécessairement entier, et on doit calculer x à partir de i dans la boucle.

De plus, en Première, il sera extrêmement facile d’initier mes élèves aux suites géométriques, puisqu’il suffit de modifier un caractère pour cela :

for(r=1;r<=10;r*=1.1){
   ....
}

(ici on calcule les termes successifs r d’une suite géométrique de premier terme 1 et de raison 1,1).

Le début de ce TP (où il fallait construire un nuage de points) a montré que la boucle consistant à faire quelque chose (ici, tracer un point) 100 fois est beaucoup plus simple à saisir que celles où on utilise les valeurs successives que prend l’indice de la boucle. Ce qui montre que les élèves saisissent bien que dans

for(indice=1;indice<=100;indice++){
   ....
}

on fait quelque chose 100 fois (bien que 100-1=99 et pas 100) mais sans savoir que la valeur de l’indice est successivement égale à 1 puis 2 puis 3 etc. Sans doute parce qu’il s’agit des fameuses affectations successives d’une même variable, difficulté évoquée dans l’onglet "TP 1". Ce qui montre aussi pourquoi la seule boucle du langage LOGO est celle où l’indice n’est pas nommé...

Le TP est ici

TP 4

Enfin de la vraie algorithmique : Le sujet


Écrire un algorithme qui, à partir de la représentation graphique d’une fonction affine (une droite), donne son coefficient directeur et son ordonnée à l’origine.

Le but de ce TP était de mettre les élèves en situation active face aux fonctions affines : Au lieu de seulement demander aux élèves d’appliquer les formules préalablement apprises par cœur, ils avaient à les transformer en algorithmes, notamment à utiliser le fait que l’ordonnée à l’origine est l’ordonnée d’un point de la droite.

Voici la production d’un élève qui n’a pas utilisé JavaScript !

Bouger les points pour voir en quoi cette production est plus puissante que quelques exercices sur des droites fixes ; l’élève en question a vite connu par cœur les formules du fait qu’il les a traduites dans le langage de CaRMetal.

Le TP est ici

TP 5

Pour calculer la moyenne de 100 nombres, il faut additionner ces nombres, puis diviser la somme par 100. C’est l’addition qui est difficile. Dans le cas présent il s’agissait de calculer une distance moyenne.

Remarque d’une élève :


Pour additionner 100 nombres, on commence par additionner les deux premiers nombres ; puis additionner le troisième nombre à la somme précédente, etc.

Peu d’élèves (et en particulier pas elle) ont réussi à écrire le programme, c’est-à-dire à passer à la description (algorithmique) suivante :

  • On crée une variable s qu’on initialise à 0 ;
  • Dans une boucle, on additionne à s la nouvelle distance (100 fois) ;
  • Quand on a fini, on divise s par 100

Et lorsqu’on veut additionner les valeurs successives de l’indice, une difficulté supplémentaire s’installe puisqu’il faut utiliser les valeurs de l’indice.

En fait il s’agit d’une définition récurrente (et non itérative comme on eût pu le croire) de la somme, par

$$\sum_{k=0}^n u_k = u_n + \sum_{k=0}^{n-1} u_k $$

La difficulté semble pouvoir être contournée par l’utilisation du mode pas-à-pas. Ou en y revenant souvent "jusqu’à ce que ça rentre" (ça a pris du temps). Les élèves ont trouvé que l’animation visible ici les a aidés à comprendre (c’était le corrigé d’un contrôle sur la somme des premiers entiers). Voir le film se dérouler au ralenti semble donc aider à la compréhension de la boucle et du rôle qu’y joue l’indice (avec la récursivité, ou l’usage d’un tableur, on évite également la difficulté, en cachant l’algorithme...)

Le TP est ici

TP 6

Algorithmiquement parlant, compter, c’est presque pareil qu’additionner :

  • On crée une variable s qu’on initialise à 0 ;
  • Dans une boucle, on effectue 100 tests ; chaque fois que le test réussit, on incrémente s ;
  • Quand on a fini, on divise s par 100 pour avoir la fréquence des succès.

Il n’y a donc que deux différences par rapport au calcul de moyenne du TP 5 :

  1. Au lieu d’additionner la variable à s, on additionne 1 à s
  2. On ne fait cette addition que lorsque le test réussit.

Le TP, relaté ici, portait sur la méthode de Monte-Carlo, utilisée en l’occurence pour calculer une valeur approchée de $\pi$. Il a servi de prétexte à l’introduction des tests dans un contexte graphique, avec un coloriage conditionnel des points du nuage :

La similitude entre ce TP et le précédent laissait augurer que les mêmes difficultés apparaitraient. Ce fut le cas. Cependant en fin d’année scolaire une sorte de déclic s’est produit chez la plupart des élèves, qui leur a donné d’un coup l’impression de comprendre l’itération et les tests. Rétrospectivement, j’ai l’impression que les TP 5 et 6 ont été des graines semées en été (décembre et février, à la Réunion, c’est l’été) et qu’elles ont mis 4 mois à germer. Pour d’autres élèves, elles pourraient bien germer en Première (à part le fait qu’il semble y avoir une très forte corrélation entre les élèves qui comprennent vite comment fonctionne l’algorithmique, et ceux qui sont passés en Première S ; les élèves qui ont eu le plus de mal en algorithmique sont en général partis en Premières STG et STI, et ne feront donc plus d’algorithmique).

TP 7, 8 et 9

Le "TP" 7, relaté ici, n’était pas vraiment un TP ; c’était plutôt une activité préparatoire au cours de statistiques, où les élèves devaient, avec le classique nuage de points, trouver une distance médiane, ainsi que des quartiles (sans en dire le nom).

Pour trouver la médiane de 100 valeurs, il faut les trier. Pour les trier, il faut les stocker. Pour les stocker, il faut un tableau. Or les tableaux ne sont pas au programme de Seconde... Ceci dit, leur présence dans Scratch et dans AlgoBox suggère leur utilité. Et une fois qu’on utilise des tableaux dans AlgoBox, on n’a plus besoin des TP 5 et 6 puisque des instructions AlgoBox existent déjà pour les calculs de moyenne (ainsi que les médiane et quartiles...).

Les élèves ont donc brièvement été formés aux tableaux sous la forme d’un exercice sur les tableaux d’effectifs (visible ici). Et une fois qu’on a mis les distances dans un tableau, un algorithme de tri serait non seulement beaucoup trop compliqué pour l’aborder en Seconde, mais inutile puisque JavaScript en possède un (Quicksort implémenté comme un "objet" JavaScript).


Les TP 8 et 9 étaient des introductions aux boucles "tant que", par des jeux de hasard (on joue tant que la partie n’est pas gagnée). Ce n’étaient pas de vrais TP mais les élèves avaient juste des scripts à copier, puis à tester. Le TP 8 est ici (jeu du lièvre et de la tortue) et le TP 9 ici (simulation d’une marche aléatoire à deux dimensions) [6]

Le bilan sur cette partie du programme d’algorithmique est que les boucles "tant que" sont trop difficile pour que les élèves les assimilent sur le coup, et qu’il vaut donc mieux les reporter à la classe de Première, ou les faire en début d’année de Seconde pour que les élèves aient le temps de les "digérer". Par exemple, on peut envisager de les faire avant les boucles à nombre prédéterminé d’exécutions en simulant celles-ci. Ainsi la somme des 10 premiers entiers naturels non nuls

var s=0;
for(i=1;i<=10;i+=1){
   s+=i;
}

peut se faire avec

var s=0, i=0;
while(i<=10){
   i+=1;
   s+=i;
}

Le résultat théorique illustré ici stipule que toute fonction récursive primitive est une fonction récursive(!)

Un résultat imprévu du TP 8 a été une variation innovante du jeu du lièvre et de la tortue, inventée par un élève, et visible ici. Bon cinéma !

TP 10

Face à un énoncé du type


Un fleuriste vend des roses à 1,50 € pièce et des tulipes à 1,60 €
pièce. Rachid achète un bouquet pour Marina. Le bouquet, qui contient 13 fleurs, lui coûte 20,30 €.
Quel est le nombre de roses et le nombre de tulipes dans ce bouquet ?

La méthode attendue est la traduction de l’énoncé en le système

$$\left\{ \begin{array}{rcl}1,5 x +1,6 y &=& 20,3 \\ x+y &=& 13 \end{array} \right.$$

puis sa résolution par exemple avec la méthode par substitution.

Mais lorsqu’on sait que x et y sont des entiers, on peut effectuer une boucle à deux niveaux pour trouver assez vite cette solution : Comme il est évident que ni x ni y ne peut dépasser 13, le script suivant (améliorable !) donne la solution :

for(x=0;x<=13;x++){
   for(y=0;y<=13;y++){
       if((1.5*x+1.6*y==20.3) && (x+y==13)){
           Println("x="+x+" et y="+y);
       }
   }
}

Ce TP portait sur l’application de cette méthode à la résolution d’équations congruentielles, extraites des archives du Rallye Mathématique de la Réunion. C’est mon préféré parmi tous les TP de cette année scolaire. Le plus réussi aussi. On notera qu’il utilisait la notion de reste euclidien ("modulo") qui n’est pas au programme de Seconde...

Il y a dans la production de certains élèves une forme de beauté :

L’énoncé est ici

TP 11

Comme pour les TP 7 à 9, il s’agissait juste pour les élèves de tester un script tout fait, dans le but de simuler avec un autre outil que le tableur, des intervalles de confiance (avec leur dessin par CaRMetal qui fait ça très bien).

Le TP se terminait par une narration de recherche dont le but était de trouver une fonction f vérifiant

xf(x)
25 0,2
100 0,1
400 0,05

avec quelques bonnes surprises visibles ici.

TP 12

Le dernier TP n’était initialement pas prévu. La salle d’informatique s’est en effet inopinément libérée à cause de la fin d’année scolaire, et j’ai voulu en profiter pour expérimenter autre chose : JavaScript dans du html (donc cette fois-ci, sans CaRMetal).

Le sujet (le TP n’était pas noté) demandait de créer une page html avec une table trigonométrique (des cosinus), au degré près, engendrée dans un esprit très "web 2.0" par JavaScript.

Il a fallu cette fois-ci initier rapidement les élèves à un nouvel outil (un éditeur de texte) et au langage html. Pour cela un gabarit leur avait été distribué, avec le minimum nécessaire pour un fichier html, et ils ont eu à le recopier (ce qu’ils adorent faire) dans l’éditeur de texte :

Effet imprévu de ce TP : Il a permis de réviser les conversions de degrés en radians, et pour une fois la nécessité de ces conversions est apparue spontanément aux élèves ("À quoi ça sert les radians ? Ben, à faire du JavaScript !").

L’énoncé est ici


notes

[1parce que Python est simplement typé, et qu’en reconnaissant 4 et 5 comme des entiers, il effectue une division euclidienne. Le remède est de placer un point décimal à l’issue de l’un des deux nombres, par exemple "4./5". J’ai tout simplement eu peur d’affronter en classe cette difficulté, peut-être ai-je eu tort ; à l’heure où j’écris ces lignes, je n’ai pas connaissance d’un récit de TP Python en classe de Seconde.

[2Depuis avril 2010 AlgoBox est muni d’un éditeur de texte pour les élèves, nombreux apparemment, qui préfèrent pianoter que cliquer

[3En créant CaRMetal, Éric Hakenholz a utilisé comme base de travail, le moteur de géométrie dynamique de CaR : En préférant modifier de l’existant que créer ex nihilo, appliquerait-il avec l’éditeur JavaScript sa propre méthode de programmation, en incitant ses élèves à travailler de la même manière ?

[4Un "programme de calcul" comme on en présente dans cet onglet n’est pas un algorithme, puisqu’on ne connaît pas le problème à résoudre, et que d’ailleurs il n’y a pas de problème à résoudre. L’entraînement à l’algorithmique peut se faire avec ce genre de programmes de calcul mais c’est semble-t-il déjà le cas au collège, et cette pratique est incompatible avec l’enseignement basé sur problématique.

[5on peut toutefois le simuler.

[6une marche aléatoire à 3 dimensions est simulée dans cet article.

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