RICM4: Évaluation de Performance

Table of Contents

Sitemap

---> misc
| ---> 2016
| ---> 2015
| ---> 2014
| ---> 2013
| ---> 2012
`--> Agenda

Informations Générales

Jean-Marc Vincent est chargé des cours et Arnaud Legrand s'occupe des TDs.

Le planning avec les salles de cours est disponible (pour les cours à Polytech le jeudi de 8h00 à 9h30) et (pour les TD à l'UJF le vendredi de 11h30 à 13h00).

Le planning avec les salles de cours est disponible là pour les cours à Polytech et là pour les cours à l'UJF.

La page de l'an dernier est ici. La page de l'année précédente était maintenue par Florence Perronnin et est disponible ici.

Programme du cours

Semaine Cours (Jeudi, 8h00, voir ADE) TD (Vendredi, 11:30, F204 en général mais vérifier sur ADE)
3 Intro (AL) Mesures de performance réseau (AL)
4 Analyse de donnée, corrélation (JV) Journée de la neige
5 Régression linéaire (JV) Mesures de performance réseau (AL)
6 Files d'attente simple (contention, Kendall, stabilité, Little) (JV) Visualisation avec ggplot2 (présentation de ggplot2) (AL)
7 Vacances Vacances
8 Réduction de variance (JV) TD Réduction de variance (JV)
9 Introduction aux chaînes de Markov (JV) DM1 + TD Random walk (AL)
10 Chaînes de Markov (JV) TD Chaîne de Markov (AL)
11 Processus de Poisson (AL) TD Aloha (AL)

Mesures de performance réseau

L'objectif de ces deux TPs est de réfléchir à comment faire des mesures réseau et à comment les analyser. De la même façon que traceroute a été inventé pour détecter et étudier des problèmes de routage, on a désormais besoin d'outils permettant de détecter des problèmes de congestion et de dimensionnement de réseau. La problématique proposée est donc celle de la mesure des performances de liens réseau. Idéalement, on aimerait disposer d'un outil permettant de connaître la capacité des liens utilisés d'une source à une destination. C'est un problème délicat qui a généré beaucoup de recherche il y a 15-20 ans mais pour s'y attaquer, il faut d'abord faire des mesures pour comprendre les problèmes pratiques qui se posent. Voici quand même quelques refs sur le sujet si ça vous intéresse:

Mesures

Dans le cadre de ces TPs, voici le genre de commandes qui peuvent être utilisées pour collecter des mesures à moindre coût:

ping -D liglab.imag.fr > liglab.log 2>&1
ping -D liglab.imag.fr -s 20480 -i .2

while true ; do for i in 16 60 600 1600 ; do ping -c 2 -D liglab.imag.fr -s $i -i .2 | grep from; done ; done

# Celui ci permet de se prémunir d'un certain nombre de biais et
# de collecter relativement rapidement des mesures
while true ; do \
    export j=$(($RANDOM%2000)) ; \
    ping -c 1 -D liglab.imag.fr -s $j  | grep from ; \
    sleep .2 ; \
done > /tmp/liglab2.log

On peut alors leur mettre un coup de grep et de sed pour les reformater. Là, j'avais choisi de faire quelque chose d'un poil robuste (en perl) et qui me rapporte les lignes non conformes à ce qui est attendu.

  $#ARGV==1 or die "Usage: convert.pl <input.log> <output.csv> -->'$#ARGV'";
  $input = $ARGV[0];
  $output = $ARGV[1];
  open(INPUT,$input) or die;
  open(OUTPUT,"> $output") or die;
  $l=<INPUT>;
  print OUTPUT qw(time,size,name,ip,seq,ttl,delay)."\n";

  while(defined($l=<INPUT>)) { 
      chomp($l);
      if($l eq "") { last; }
      if($l =~ /^\[(.*)\] (.*) bytes from (.*) \((.*)\): icmp_seq=(.*) ttl=(.*) time=(.*) ms$/) {
          my($time,$size,$name,$ip,$seq,$ttl,$delay)=($1,$2,$3,$4,$5,$6,$7);
          print OUTPUT (join(',',($time,$size,$name,$ip,$seq,$ttl,$delay))."\n");
      } else { print "---> $l\n"; }
  }
---> [1421761684.770828] 21 bytes from lig-publig.imag.fr (129.88.11.7): icmp_seq=1 ttl=60
---> [1421761706.146320] 9 bytes from lig-publig.imag.fr (129.88.11.7): icmp_seq=1 ttl=60
---> [1421761748.647974] 9 bytes from lig-publig.imag.fr (129.88.11.7): icmp_seq=1 ttl=60
---> [1421761788.500516] 9 bytes from lig-publig.imag.fr (129.88.11.7): icmp_seq=1 ttl=60
...

Effectivement, la valeur time n'est pas fournie pour ces lignes là…

Quoi qu'il en soit, voici le genre de données que j'ai pu récupérer. Si vous n'avez pas pu faire de mesures par vous même (ce qui est dommage…), vous pouvez les utiliser…

for i in `find RICM4_EP_ping -name '*.gz'` ; do echo "- [[http://mescal.imag.fr/membres/arnaud.legrand/teaching/2014/$i][$i]]"; done

Voici une analyse en R+markdown qui est le genre de choses qui me parait être accessible. (et voici les sources…)

Devoirs

Devoir 1

Voici l'énoncé et le Rmd avec le code de départ (dont le résultat est disponible sur rpubs). Et voici enfin un corrigé.

  • Le but de Q1 était que vous compreniez l'influence des paramètres sur les caractéristiques (espérance et variance) du temps de service. Un certain nombre d'entre vous sont passés complètement à coté et ont utilisé des lois dont l'espérance n'était pas normalisée à 1, d'où des simulations sans sens (genre injecter 0.8 tâches par seconde alors que le serveur n'est capable que de traiter au mieux que 0.5 tâches par seconde) et des analyses complètement délirantes.
  • Pour Q1, souvent, vous faites un sequence plot avec geom_point. Ce n'est vraiment pas la meilleure façon de comparer des distributions. Utiliser un histogramme est bien plus adapté… La représentation de Barthelemy et Mammar (avec le geom_bar et les gros points rouges) qui représente la moyenne et la variance était une très bonne idée.
  • Pour Q2 et Q3, un point vraiment important à comprendre, c'est que dans vos graphes où vous représentez le temps de réponse en fonction du débit d'entrée, il fallait borner les ordonnées. En effet, vous aviez parfois des moyennes vraiment très très élevées. Ça correspondait à des situations où le système n'était pas stable (en particulier avec pmtn_restart). Dans ce cas, le système emmagasine les tâches et, une fois que toutes les 10,000 tâches sont arrivées, les relargue les unes après les autres. Les valeurs ainsi mesurées ne sont absolument pas représentatives du temps de traitement. Dans ce type de situation, le temps moyen a d'ailleurs tendance à augmenter avec le nombre de tâches…

Fotsing: http://rpubs.com/emfotsing/65717

  • Q1

    Vous n'avez pas compris la questions. Ce qu'on voulait étudier, c'est la distribution du temps de service. Regardez le corrigé.

  • Q2

    Vous n'avez du coup pas compris ce qui importait dans les paramètres de la loi du temps de service. Quand vous faites:

    All_Policies_Experiments_Exp <- Gen_All_Policies_Experiments(policy="exp",x=1/5)
    

    vous considérez un serveur capable de traiter en moyenne \(1/5=0.2\) tâches par seconde. J'avais demandé de normaliser le temps de service à 1. Du coup, quand dans la suite, vous utilisez des taux d'arrivée de 0.2, 0.4, 0.6 ou 0.8, vous injectez les tâches à une vitesse bien supérieure à ce que le serveur est capable de traiter. C'est pour ça que vos temps de service sont aussi élevés. Le système est saturé et ces valeurs n'ont pas de sens. Regardez la correction.

    Ce qui est curieux, c'est que vous avez visiblement compris que le système était instable. Mais vous n'avez pas compris à quoi c'était dû (un serveur trop lent ici par rapport à la charge que vous injectiez) et du coup, vous n'avez pas pu observer grand chose.

Guo Kai & Yao Longfei: http://rpubs.com/GUOKAI/65454

  • Q1

    Dans l'ensemble, vous avez inversé la question 1 et la question 2 mais bon, passons. En ce qui concerne la question 1, vous n'avez pas compris ce que je vous demandais. On s'intéressait à la distribution du temps de service et faire un sequence plot n'est pas la meilleure représentation… De même pour la question 2, tracer dans un graphe la moyenne et dans un autre la variance, n'est pas la meilleur représentation. L'utilisation d'intervalles de confiance aurait été bien plus adaptée et vous aurait permis de comparer les politiques entre elles. Regardez bien la correction.

    Sinon, la longue série des p111, p112, …, p444. BERK! Quelle idée d'abuser ainsi du copier/coller. Les boucles for, c'est fait pour quoi selon vous ?

    Pareil pour la façon dont vous faites l'agrégation. Je vous avais justement montré plyr pour éviter ce genre d'horreurs…

    Pour ce qui est de l'analyse que vous faites, c'est étrange car vous raisonnez comme si la loi du temps de service était un choix. C'est plutôt quelque chose d'imposé par le système que vous observez. Ce sur quoi vous pouvez plutôt agir, c'est la politique de service…

  • Q2
  • Q3

    Pas de réponse

Vincent Mesnier & Jake Morison

  • Q1

    Ce ne sont pas les représentations les plus adaptées. Un histogramme aurait été plus judicieux. Il aurait également été mieux de représenter les différents histogrammes sur le même graphe pour mieux les comparer.

  • Q2

    Le graphe est très bien. Par contre, votre lecture est étrange (d'ailleurs, c'est "amusant", c'est exactement les mêmes erreurs que Saussac et Toussaint):

    • "une evolution plutot régulière", tout à fait d'accord
    • "(elles suivent à peu prés une droite)". Hein ? Ben non, ce n'est pas droit.
    • "il y en a une qui se dermarque : la bleue (préemption avec restart).". Effectivement.
    • "Cette aumgentation est proche de l’exponentielle." Non, vous ne pouvez pas dire ça. Vous n'avez que deux points et une exponentielle, ça n'est pas une asymptote. Ça "explose", oui, mais pas comme une exponentielle.
    • "Si nous regardons de plus prés la courbe orange (sans préemption), on remarque qu’elle semble etre la plus efficace car elle fourni pour chaque valeur un temps de service minimal." Non, justement, si vous regardez bien, vous verrez que vos intervalles de confiance se recouvrent et que, même si c'est pmtn, la verte, la plus basse, ça n'est pas significatif.
  • Q3

    Encore une fois ici, vos erreurs sont exactement les mêmes que celles de Saussac et Toussaint. Je n'aime pas ça du tout.

    Ce qui nous intéressait ici, c'est plutôt pour une loi donnée, comment les différentes politiques se comparent les unes aux autres. Et au delà de constater que telle ou telle politique se comporte mieux que telle autre, ce qui est important, c'est de chercher à expliquer pourquoi… Lisez bien mon corrigé.

    Enfin, concernant votre conclusion qui lie les statistiques au bikinis, je ne suis pas sûr qu'elle soit des plus adaptées ici…

Thibault SAUSSAC​ & Sébastien TOUSSAINT​

  • Q1

    Pourquoi faire un sequence plot avec geom_point ? Il aurait bien mieux valu utiliser un histogramme pour comparer les distributions et voir la répartition des valeurs.

    Votre conclusion est la bonne par contre: "Les autres varient avce plus ou moins d’amplitude mais au finalement elle on toute une moyenne de 1".

  • Q2

    "Cette aumgentation avoisine l’exponentielle." No comment. Enfin, si, vous ne savez visiblement pas ce qu'est une exponentielle. :)

    Erm. pour cette question, je vous renvoie à ce que j'ai dit à Mesnier et Morisson puisque vous avez fait la même analyse et les mêmes erreurs.

  • Q3

    Pareil, allez voir ce que j'ai écrit pour Mesnier et Morison. Ce sont les mêmes erreurs. Je n'aime pas ça. Mais au moins, vous, vous avez remarqué qu'il y avait quelque chose de surprenant pour gamma(0.2,5) et pmtn_reset. Dans tous les cas, ce qui manque, c'est l'interprétation.

Anthony Leonard & Jérémy Hamerer: http://rpubs.com/leonaran/65254

  • Q1

    Mettre toutes les lois sur le même graphe est une bonne idée. Par contre, cette représentation ne permet pas de bien voir comment se répartissent les différentes valeurs. Il aurait bien mieux valu utiliser un histogramme qu'un sequence plot. C'est dommage en fait car vous avez justement dessiné la distribution de loi gamma. Pourquoi n'avez vous pas fait pareil pour les autres lois ?

  • Q2
    • Il aurait fallu borner le temps de réponse. C'était bien trop élevé de toutes façons pour que ça ait du sens.
    • Du coup quand vous dites "On constate que les temps de réponse sont similaires ainsi que leurs variabilités pour les politiques non préemptive, préemptive avec réinitialisation et préemptive avec reprise.", vous n'en savez rien. C'est trop petit pour que vous puissiez être sûrs. Regardez le corrigé.
  • Q3

    Même problème que précédemment. Si vous ne bornez pas les ordonnées, les graphes sont illisibles.

    Vos analyses sont cependant correctes malgré ce handicap!!!

Luc Libralesso, Olivier Soldano: http://rpubs.com/librallu/dm1-ep

  • Q1

    L'idée de supprimer les 200 premières tâches est intéressante. Vous dites que c'est pour améliorer la variance. Avez-vous vérifié si vous observiez une différence? Si ça "améliorait" effectivement les choses?

    • Votre étude des distribution est très bien. Juste une petite remarque, je ne suis pas sûr que les couleurs soient très utiles dans l'histogramme.
  • Q2

    Nickel. Petite remarque, c'est outlier, pas outsider. :)

    L'utilisation de l'échelle log pour mieux voir est une bonne idée, même si ici, il vaut mieux restreindre l'échelle. En effet, quand les valeurs de temps de réponse sont trop grande, cela signifie que:

    1. le système n'est pas stable et la valeur mesurée n'a pas de sens, elle ne correspond pas à ce que vous souhaitez (l'espérance n'est pas forcément définie et la valeur finie que vous calculez n'a pas de sens car les temps de réponse des dernières tâche correspondent à une situation où vous avez arrêté d'injecter des tâches…);
    2. personne n'utiliserait un système avec un tel temps de réponse et d'autres phénomènes surviendraient (swap, client quittant le système, …) donc le modèle n'a plus grand sens de toutes façons;

    Dans ce cas, il vaut donc mieux borner arbitrairement les ordonnées.

    En ce qui concerne votre analyse, restart est effectivement très mauvaise pour les raisons que vous évoquées. Les autres ont un comportement similaire et pour cause. Lors d'un reset, comme la loi exponentielle est sans mémoire, si un nouveau temps est tiré c'est exactement comme le cas de pmtn. Il n'y a aucune différence entre ces trois politiques en raison des propriétés de la loi exponentielle.

  • Q3

    Nickel. Vous avez effectivement compris comment ça marchait.

Romain Barthelemy & Malek Mammar: http://rpubs.com/Patator/65102

  • Q1

    Pas mal. La représentation en sequence plot n'est cependant pas la meilleure pour comparer des distributions. Votre dernier graph (avec le geom_bar et les gros points rouges) qui représente la moyenne et la variance est par contre une très bonne idée.

  • Q2

    Mais pourquoi tester des paramètre différents de la loi exponentielle pour le temps de service ? Ça n'a plus aucun sens, même si vous avez effectivement compris ce que cela signifiait (accélérer ou ralentir le serveur).

    Et surtout, avec une simulation aussi longue et pmtn_restart qui explose très vite, il fallait absolument borner les ordonnées. En effet, le système est saturé, emmagasine les tâches et une fois que toutes les 10,000 tâches sont arrivées, les relargue les unes après les autres. Les valeurs ainsi mesurées ne sont absolument pas représentatives du temps de traitement.

    Je ne sais pas trop quoi penser de votre étude du nombre d'interruption en fonction du débit d'arrivée.

  • Q3

    Enfin, vous zoomez! :) Parfois, vos analyses sont trop focalisées sur la comparaison des courbes plus que sur ce qu'elles mettent en valeur. Par exemple, quand vous dites à propos de reset "Quand le délai inter arrivée est très faible (lambda tend vers 1), si le temps de service a tendance à être grand alors on se rapproche de la courbe du restart." En fait, ce qu'il se passe, c'est que le système devient saturé.

    Vous avez globalement effectivement compris ce qu'il se passait avec reset et restart et pourquoi reset s'en sortait de mieux en mieux quand la variance du temps de service était très grande. Vous avez aussi compris que j'attendais plus de texte (d'analyse) que de code… C'est bien. :)

Quentin Torck, Xueyong QIAN: http://rpubs.com/xuey90/64905

  • Q1

    Vous avez des phrases qui ne se terminent pas. Genre "Dans un second temps nous tracerons les courbes précedente sur des".

    Vous n'avez absolument pas compris à quoi correspondait les paramètres des différentes loi et ce que vous avez étudié par la suite n'a aucun sens. Je prend un exemple. Vous faites:

    service2=Service(40,typeservice = "uni",id,id)
    

    Ça correspond à générer 40 temps de services uniformément distribués entre id et id… autrement dit égaux à id. Quel sens donnez-vous à ceci ?

    Sinon, vous ne pouvez pas dire qu'une évolution est exponentielle (" le temps d’éxecution pour le service 3 est exponentielle") à partir du moment où une fonction croit plus vite que d'autres…

    Le reste de l'analyse n'a hélas pas grand sens. ;(

  • Q2

    Concernant votre problème de compilation, pas facile de dire avec un bout de code mal mis en forme mais quand je l'ai recopié, réindenté et remplacé les guillemets utf8 par des guillemets classique, je n'avais pas de problème de compilation.

EUDES Robin, ROSSI Ombeline: http://rpubs.com/Eudesr/64883

  • Q1

    L'intérêt de cette question était de vérifier que vos appels à ces lois étaient cohérents, i.e., que vous utilisez des paramètres permettant d'avoir un temps de service moyen de 1 et de réaliser que ces lois différaient par leur variance.

  • Q1

    Du coup, vous n'avez pas réalisé qu'en mettant x=0.5, vous simuliez un serveur capable de traiter 0.5 tâches par unité de temps et pas 1. Du coup, vous saturez votre système très rapidement et les valeurs que vous calculez lorsque vous injectez 0.8 tâches par unité de temps n'ont juste aucun sens… :(

  • Q3

    Pareil là, mais pourquoi ??? Quand vous faites:

      res <- rbind(res,FileLIFO(n=1000,lambda=lambda_seq[i],typeservice="gamma1",x=1,y=1/lambda_seq[i],policy="npmtn"))
    

    En faisant ça, vous modifiez la variance du temps de service en fonction du taux d'arrivée… Ça n'a aucun sens. :( Du coup, le reste des analyses et des courbes non plus. :(

Devoir 2

Q1
Vous modifierez le code précédent pour étudier les performances d'une file implémentant la politique SRPT (Shortest Remaining Processing Time First), c'est à dire qui exécute en priorité la tâche pour laquelle il reste le moins de travail à effectuer. Comme pour la politique LIFO, il existe plusieurs variantes à cette politique:
  • SRPT_pmtn: qui s'assure qu'à chaque instant, elle traite la tâche pour la quelle il reste le moins de travail à effectuer. En conséquence, elle s'interromps à chaque fois qu'une nouvelle tâche arrive dans le système et éventuellement sélectionne cette tâche si son temps de service (sa quantité de travail) est plus petite que la quantité de travail restant de la tâche en cours d'exécution.
  • SPT_pmtn: fonctionne comme la précédente mais base sa décision d'ordonnancement sur le temps de service de la tâche et pas sur la quantité de travail restant.
  • SPT: fait la même chose que les précédentes mais ne s'interromps pas quand une nouvelle tâche entre dans le système. Cette stratégie non préemptive revient donc à exécuter systématiquement (et d'une seule traite) la tâche dont le temps de service est le plus petit au moment de la décision d'ordonnancement.
Q2
Vous évaluerez les performances (en terme de temps de réponse moyen) de ces différentes stratégies et les comparerez à celle de la politique FIFO.
Q3
Vous étudierez également la distribution du temps de réponse et en particulier les valeurs extrêmes comme le temps de réponse maximum).

Note: afin que les comparaisons entre les différentes politiques soient les plus précises possibles, il pourra être intéressant de restructurer la simulation afin que chacune des politiques soient évaluées avec un workload commun (dates d'arrivées et temps de service).

Voici ma correction de ce DM: http://rpubs.com/alegrand/73059.

Leonard & Hammerrer

Héhé, cette fois-ci, vous avez représenté la densité des lois gamma.

Rien à dire. C'est bien. Vous avez compris comment ça marchait.

Thibault SAUSSAC & Sébastien TOUSSAINT

Wow. Vous avez finalement une fonction pour fifo et une pour srpt (comme Mesnier et Morison :( ). C'est dommage. La duplication de code, c'est mal… Et votre utilisation systématique de boucles while, c'est vraiment bizarre.

Pour Q2, elles "explosent" toutes puisqu'il y a une asymptote pour \(\lambda=1\). srpt_pmtn est effectivement plus efficace. J'aurais aimé une interprétation, une explication de pourquoi srpt_pmtn s'en sortait mieux que les autres et de ce ça impliquait. Vos analyses sont trop du niveau "ça monte, ça descend, c'est plus grand, c'est plus petit". Il manque le "pourquoi" et qu'est-ce qu'on en conclut.

Vincent Mesnier & Jake Morison

Tiens, vous aussi, comme Saussac et Toussaint, vous avez une fontion pour fifo et une fonction pour srpt. C'est dommage. La duplication de code, c'est mal… Au moins, vous utilisez des boucles for et pas des boucles while… Comme eux, vos analyses sont trop du niveau "ça monte, ça descend, c'est plus grand, c'est plus petit". Il manque le "pourquoi" et qu'est-ce qu'on en conclut.

Robin Eudes & Ombeline Rossi (http://rpubs.com/Eudesr/71305)

Visiblement, vous vous êtes trompé dans votre implémentation car les courbes n'ont pas le comportement attendu. :(

Sinon, vous n'avez pas comparé à fifo. Regardez la correction.

Guo Kai & Yao Longfei

Visiblement, vous vous êtes trompés dans votre implémentation car SRPT_PMTN a de meilleures performances (i.e. un temps de réponse plus petit) que SPT_PMTN. Et c'est à FIFO qu'il fallait se comparer. Regardez la correction.

Mammar & Barthelemy

Effectivement, faire un set.seed au début de l'appel permet d'avoir les mêmes scénarios. C'est quand même un peu dangereux car ça limite les scénarios que vous pouvez tester…

Mais sinon, les analyses sont bonnes. Vous avez compris ce qu'il se passait.

"une valeur lambda > au débit crête" ? Mais que voulez-vous dire par là ???

Qian & Torck

Tsss, deux fonctions, une pour srpt et une pour fifo. La duplication de code, c'est mal!

Je remarque quand même qu'il n'y a pas "un seul" commentaire. Que du code, des graphiques et des sorties R.

Au vu des valeurs calculées, je pense cependant que vous vous êtes gourrés dans votre implémentation.

Luc Libralesso - Olivier Soldano

Ah, joli la modification du running element:

  waiting <<- waiting[-which(waiting == running)]

Je n'avais pas pensé à le faire comme ça, du coup, j'ai stoqué l'indice dès le départ. Bref.

Ah, et vous êtes les seuls à avoir pensé à tester votre code sur un petit scénario…

"nous nous intéresserons principalement à la loi exponentielle pour les temps de service car c’est celle qui a la variance la plus importante (voir TP précédent)." Non, vous auriez pu avoir une variance plus importante avec une gamma mais je vous demandait ce qu'il se passait pour la MM1, donc pour une loi exponentielle.

Votre comparaison des distributions du temps de réponse avec des nuages de points n'est pas probante. Le moins que vous puissiez faire, c'est de mettre du jitter (geom_jitter pour éviter l'overplotting). Et mieux, utilisez des boxplots…

Sinon vos interprétations sont bonnes.

Éric Michel Fotsing

Ton implémentation a l'air correcte mais tu l'utilises n'importe comment. Comme dans le premier DM. Je suis en partie coupable car j'ai mis du temps à vous faire un retour personnel mais par contre, je vous ai fourni une correction assez rapidement et visiblement tu ne l'as pas regardée. Sinon, tu n'aurais pas refait les mêmes erreurs (avoir un serveur qui traite en moyenne 0.5 tâches par unité de temps au lieu de 1…). Ce qui est incroyable (enfin, pas tant que ça quand on connait les propriétés de ces politiques), c'est que tu observes bien que le temps de réponse moyen est bien meilleur pour srpt_pmtn que pour spt_ptmn que pour spt et que pour fifo qui s'en sort le moins bien, mais que c'est l'inverse pour le temps de réponse maximum.

Sinon, tes analyses sont trop du niveau "ça monte, ça descend, c'est plus grand, c'est plus petit". Il manque le "pourquoi" et qu'est-ce qu'on en conclut.

À propos de l'utilisation de R

Dans ce cours, nous illustrerons une fois de plus l'intégralité de nos exemples et de nos études avec R. Je vous invite à regarder la section de la page du cours Probabilité et Simulations et qui était dédiée à ce sujet.

Bibliographie