diff --git a/Readme.md b/Readme.md
index 858cbc646bfa626ea707276db58131a90a05984a..3a66b06c1c46556aaa1013ab6162dccc42f7b8ce 100644
--- a/Readme.md
+++ b/Readme.md
@@ -51,19 +51,34 @@ Initialiser dans la fonction `experiment_load_factor` des listes `insertion_time
4. Insérer les éléments dans le dictionnaire et mesurer le temps d'insertion pour chaque élément, vérifier le nombre de réallocations mémoire (utiliser par exemple `time.time()` et `sys.getsizeof()` pour mesurer le temps et la taille du dictionnaire avant et après chaque insertion).
+La fonction time.time() a été remplacée par la fonction time.perf_counter() pour plus de précision.
+
5. Pour un facteur de charge donné, stocker les résultats dans les listes `insertion_times`, `num_resizes` et `sizes`.
## Deuxième étude
6. A quoi sert la fonction `experiment_longest` ?
+cf Script
+
## Visualisation des résultats
7. Créez quatre graphiques au format png ou pdf :
-- Un graphique du temps d'insertion en fonction du facteur de charge (obtenu question 5)
-- Un graphique du nombre de réallocations de mémoire en fonction du facteur de charge (obtenu question 5)
-- Un graphique de la taille de mémoire occupée en fonction du nombre d'éléments (obtenu question 5)
-- Un histogramme des fréquences des temps d'insertions discrétisés (code fourni, remplacer la liste vide par la bonne entrée)
+1. - Un graphique du temps d'insertion en fonction du facteur de charge (obtenu question 5)
+2. - Un graphique du nombre de réallocations de mémoire en fonction du facteur de charge (obtenu question 5)
+3. - Un graphique de la taille de mémoire occupée en fonction du nombre d'éléments (obtenu question 5)
+4. - Un histogramme des fréquences des temps d'insertions discrétisés (code fourni, remplacer la liste vide par la bonne entrée)
10. Commentez vos résultats.
+
+1: On observe que plus les facteurs de charges sont importants plus les temps d'insertions sont longs. En effet, on peut voir sur le graphique une courbe à la tendance croissante.
+Ce phénomène peut être expliqué par les risques de collision accrus et le besoin de réallouer de la mémoire pour insérer un nouvel élément lorsque le facteur de charge est élevé.
+
+2: On a inséré 1 000 éléments dans le dictionnaire et on observe un nombre de réallocations de mémoire différent entre les facteurs de charge.
+Pour le facteur de charge le plus faible, 2 réallocations ont été réalisées contre 9 pour ceux allant de 0.7 à 1.0. On atteint alors un pallier où les risques de collisions sont assez faibles pour que Python n'est plus besoin de réallouer de la mémoire afin les éviter. On en déduit donc que pour les 1000 éléments, après 9 réallocations, la mémoire ne dépasse les 2/3 de la taille du dictionnaire.
+On observe également un plateau à 8 réallocations pour les facteurs 0.4, 0.5 et 0.6. On peut alors supposer que la réallocation supplémentaire pour les facteurs suivants est causé par le remplissage immédiat des 2/3 de la mémoire. En effet, Python réalise cette action lorsque le dictionnaire est remplie au 2/3 or, 2/3 = 0.66 ce qui pourrait expliquer le plateau suivant.
+
+3: Sur le graphique représentant la taille mémoire occupée en fonction du nombre d'éléments que plus on a d'éléments dans le dictionnaire plus la taille mémoire occupée est importante. On retrouve une courbe semblable à celle correpsondante au nombre de réallocations mémoire en fonction des facteurs de charge. Ceci expliqué par le fait que selon le facteur de charge, de la mémoire est réalloué afin de permettre l'insertion d'éléments et que le facteur de charge correspond aux nombres d'éléments / taille interne de la table de hachage.
+
+4: On peut voir sur l'histogramme que le temps d'insertions dans un dictionnaire Python est rapide. En effet, malgré les coûts liés à la mémoire lors de l'insertion, ils ont été optimisés afin de rendre efficace leur utilisation.
\ No newline at end of file
diff --git a/load_factors.png b/load_factors.png
index eac5f2b1596701952c291bfb403d091cbfc2918e..c5072b4067cac37a01df7928edbc2f29c9ff91b8 100644
Binary files a/load_factors.png and b/load_factors.png differ
diff --git a/num_resizes.png b/num_resizes.png
index 4d9a4251189e3cda56171ea4712880874182038e..23a85113be074e0c9a4be40bf3cebc068225d80f 100644
Binary files a/num_resizes.png and b/num_resizes.png differ
diff --git a/sizes.png b/sizes.png
index 8405500515630c27aef2d27a84e77514242310ac..1148373f00dedc85bd8e44be54071d58c19e63e0 100644
Binary files a/sizes.png and b/sizes.png differ
diff --git a/tp_2_miso_dict.py b/tp_2_miso_dict.py
index df85f45aba73b8c1019e1064e63ff7902266cb3b..1525b791e185a6fdbbb3a70c3a35fbab2120d45d 100644
--- a/tp_2_miso_dict.py
+++ b/tp_2_miso_dict.py
@@ -79,36 +79,34 @@ def visualisation(load_factors, insertion_times, num_resizes, sizes, frequencies
"""
# Temps d'insertion en fonction du facteur de charge
plt.figure(figsize=(10, 6))
- x = np.arange(len(load_factors))
- plt.bar(x, insertion_times, color="crimson", width=0.4)
+ plt.plot(load_factors, insertion_times, marker = 'o', color="darkorange")
plt.xlabel("Facteurs de charge")
plt.ylabel("Temps d'execution")
- plt.xticks(x, load_factors)
+ plt.xticks (load_factors)
plt.title("Temps d'insertion en fonction du facteur de charge")
plt.savefig("load_factors.png")
# Nombre de réallocations de mémoire en fonction du facteur de charge
plt.figure(figsize=(10, 6))
- x = np.arange(len(load_factors))
- plt.bar(x, num_resizes, color="crimson", width=0.4)
+ plt.plot(load_factors, num_resizes, color="mediumvioletred", marker= 'o')
plt.xlabel("Facteurs de charge")
plt.ylabel("Nombre de réallocations")
- plt.xticks(x, load_factors)
+ plt.xticks(load_factors)
plt.title("Nombre de réallocations en fonction du facteur de charge")
plt.savefig("num_resizes.png")
# Taille de mémoire occupée en fonction du nombre d'éléments
+ nombre_elements = [int(factor * 1000) for factor in load_factors]
plt.figure(figsize=(10, 6))
- x = np.arange(len(load_factors))
- plt.bar(x, sizes, color="crimson", width=0.4)
- plt.xlabel("Facteurs de charge")
+ plt.plot(nombre_elements, sizes, color="darkturquoise", marker='o')
+ plt.xlabel("Nombre d'éléments")
plt.ylabel("Mémoire occupée")
- plt.xticks(x, load_factors)
- plt.title("Mémoire occupée en fonction du facteur de charge")
+ plt.xticks(nombre_elements)
+ plt.title("Mémoire occupée en fonction du nombre d'éléments")
plt.savefig("sizes.png")
# Deuxième étude
- f = list(frequencies)
+ f = frequencies
plt.figure(figsize=(10, 6))
plt.bar(range(len(f)), f)
plt.xlabel('Temps d\'insertion (s)')
diff --git a/tp_2_miso_mphf.py b/tp_2_miso_mphf.py
index 6620250cd81f9193205975c02249669672aae1f6..7913185b07bca03918ad650365c0dccbcc078db9 100644
--- a/tp_2_miso_mphf.py
+++ b/tp_2_miso_mphf.py
@@ -78,8 +78,6 @@ def construction_mphf(set_kmer, n, gamma=2, nb_niveaux=3):
# On fusionne tous les tableaux un même tableau
grand_tableau.extend(tableau)
- # on initialise une variable rang qui contiendra les rangs des kmers
- rangs = []
# On initialise le rang maximal par 0
max_rang = 0
# On parcours tous les kmers dans set_kmer
@@ -224,5 +222,5 @@ if __name__ == '__main__':
print(abs(hash(kmer)))
h= get_hash_mphf(mphf, kmer)
print(h)
- print("hello world")
+
print(create_hash_table(set_kmer, 10))
\ No newline at end of file