Update README.md

README.md

@@ -163,7 +163,7 @@ Pour vérifier notre hypothèse, nous avons tout simplement formulé les graphes
 
 ### Résultats expérimentaux
 
-Voici un [graph](https://git.unistra.fr/i.klein/P4a/-/blob/master/Projet/graph_mem2.png) qui représente le temps utilisateur et la mémoire nécessaire à la réalisation des tests. Notre hypothèse est ici partiellement inexacte ; La LinkedList (en bleu clair) prend tout autant de ressourse en mémoire et en temps que l'ArrayList (en bleu foncé) lorsque le nombre d’utilisation d’une fonction reste sous un certain seuil.
+Voici un [graph](https://git.unistra.fr/i.klein/P4a/-/blob/master/Projet/graph_memoire.png) qui représente le temps utilisateur et la mémoire nécessaire à la réalisation des tests. Notre hypothèse est ici partiellement inexacte ; La LinkedList (en bleu clair) prend tout autant de ressourse en mémoire et en temps que l'ArrayList (en bleu foncé) lorsque le nombre d’utilisation d’une fonction reste sous un certain seuil.
 On voit que la granularité n’est pas assez fine sur mes graphiques. C’est pourquoi j’ai décider de modifier celle-ci dans le fichier perf3.sh et de relancer un jeu de donnée data2.dat.
 La nouvelle granularité du nombre d’utilisations d’une fonction est donc la suivante :
 	*1
@@ -175,6 +175,7 @@ La nouvelle granularité du nombre d’utilisations d’une fonction est donc la
 	*1000
 	*tous les 500 pas jusqu’a 8000.
 J’ai lancé ce dernier jeu de test trop tard, et il prendra donc fin après minuit.Donc, il restera partiel.
+Cet autre [graph](https://git.unistra.fr/i.klein/P4a/-/blob/master/Projet/graph_temps.png) représente bien la différence de temps nécessaire pour la fonction de recherche entre l'ArrayList et la LinkedList, différence aussi dans ce [graphe](https://git.unistra.fr/i.klein/P4a/-/blob/master/Projet/perf.png)-ci.
 
 
 ### Analyse des résultats expérimentaux