Rapport

Projet 3 - Impl´ementation et analyse des tables de hachage
Kabbali Rizlaine
10 mai 2020
Contents
1 Introduction 2
2 M´ethodes 2
2.1 Choix d’impl´ementation pour les algorithmes de hachage et de gestion de collision . . . . . . 2
2.1.1 Remplacement des valeurs supprim´ees par des valeurs sentinelles dans le double hachage 2
2.1.2 Garantir un r´esultat impair pour h2(key) ......................... 2
2.2 Choix d’impl´ementation pour les tests et les graphiques . . . . . . . . . . . . . . . . . . . . . 2
3 R´esultats 3
3.1 Vitesse d’insertion et de suppression dans une table avec gestion de collision par chaˆınage . . 3
3.1.1 Insertion............................................ 3
3.1.2 Suppression.......................................... 3
3.2 Vitesse d’insertion et de suppression dans une table avec gestion de collision par adressage
ouvert(doublehachage) ....................................... 5
3.2.1 Insertion............................................ 5
3.2.2 Suppression.......................................... 5
3.3 Nombre de sondages moyen `a l’insertion et `a la suppression . . . . . . . . . . . . . . . . . . . 6
3.4 Nombre de collisions en fonction de l’algorithme de hachage utilis´e . . . . . . . . . . . . . . . 6
3.4.1 Hachage de 10000 cl´es compos´ees des 26 lettres de l’alphabet dans un tableau de 128
emplacements......................................... 6
3.4.2 Hachage de 10000 cl´es compos´ees de 93 caract`eres UNICODE dans un tableau de 128
emplacements......................................... 7
3.4.3 Hachage de 10000 cl´es compos´ees de 93 caract`eres UNICODE dans un tableau de 1024
emplacements......................................... 7
4 Discussion sur l’hypoth`ese de hachage uniforme 8
5 Conclusion 8
1

1 Introduction
Il nous a ´et´e demand´e dans ce travail d’impl´ementer diff´erents algorithmes de hachage et de tester leur
efficacit´e afin de comprendre l’impact qu’ont certains param`etres sur celle-ci.
2 M´ethodes
2.1 Choix d’impl´ementation pour les algorithmes de hachage et de gestion de
collision
J’ai commenc´e par impl´ementer les m´ethodes de hachage telles que d´ecrites dans le pseudo-code de l’´enonc´e,
mais suite `a quelques tests et lectures, j’y ai ajout´e quelques optimisations.
2.1.1 Remplacement des valeurs supprim´ees par des valeurs sentinelles dans le double hachage
Lorsqu’une valeur est supprim´ee, elle est remplac´ee par une valeur sentinelle, qui permet de savoir que cette
place a ´et´e occup´ee `a un certain moment. De cette mani`ere, lorsqu’on utilise la m´ethode self.get(key),
celle-ci peut continuer `a chercher lorsqu’elle tombe sur cette valeur sentinelle et s’arrˆeter pour renvoyer une
KeyError d`es qu’elle tombe sur un emplacement vierge. De plus, afin d’optimiser les futures utilisations de
la m´ethode get(key) ou delete(key), lorsque l’on rencontre une valeur sentinelle avant de trouver la cl´e
d´esir´ee, celles-ci ´echangent leurs places.
2.1.2 Garantir un r´esultat impair pour h2(key)
Comme nous l’avons vu au cours th´eorique, pour que la m´ethode de gestion de collisions par double hachage
donne de bons r´esultats, h2(key) et la longueur de la table doivent ˆetre premiers entre eux. Une mani`ere
d’y arriver est de faire en sorte que h2(key) retourne un chiffre impair et que la table soit une puissance
de deux. Pour cela, je me suis tout simplement servie d’un or 0b1, qui garantit donc que le dernier bit du
r´esultat sera un 1 et qu’il sera donc impair. Une autre possibilit´e aurait ´et´e de choisir un m premier et de
faire en sorte que h2(key) renvoie une valeur inf´erieure `a m avec un modulo m, mais je ne m’attarderai pas
sur cette impl´ementation que je n’ai pas choisie, n’´etant pas celle pr´esent´ee au cours.
2.2 Choix d’impl´ementation pour les tests et les graphiques
J’ai tent´e d’´ecrire mes fonctions de timer et de mani`ere `a pouvoir tester mes m´ethodes avec diff´erents jeux
de donn´ees afin de pouvoir d´eceler les limites des algorithmes de hachage impl´ement´es. Je pr´esenterai ici
les r´esultats des tests qui m’ont paru les plus pertinents. De plus, j’ai d´ecid´e de tenir compte des temps
minimums que donne la fonction timeit.timeit afin de n´egliger au maximum les biais dˆus `a la rapidit´e du
processeur. Pour certaines figures, j’ai choisi de prendre des graphiques dont les courbes individuelles des
algorithmes ne sont pas distinguables. Je pars du postulat que l’int´erˆet ici est de voir la tendance g´en´erale
et pas le comportement d’un algorithme en particulier, sauf s’il s’en ´eloigne de mani`ere remarquable.
2

3 R´esultats
3.1 Vitesse d’insertion et de suppression dans une table avec gestion de collision
par chaˆınage
3.1.1 Insertion
La figure 1 nous montre que le temps d’insertion dans une table dont les collisions sont g´er´ees par liste chaˆın´ee
est relativement constant. Nous pouvons donc consid´erer que la complexit´e de la m´ethode d’insertion est
en O(1). L’algorithme de hachage CRC32 semble ˆetre le moins performant des trois, quel que soit le jeu
de donn´ees. Les trois algorithmes sont tr`es l´eg`erement plus performant lorsque la taille de la table est une
puissance de deux.
Figure 1: Vitesse d’insertion de 128 ´el´ements dans un tableau de 128 places
3.1.2 Suppression
Figure 2: Vitesse de suppression de 128 ´el´ements dans un tableau de 128 places
3

Malgr´e les quelques pics subis par les algorithmes CRC32 et KR la figure 2 nous am`ene aux mˆemes conclusions
que pour l’insertion. En effet, si α= O(1), dans le cas d’algorithmes de hachage uniforme, la suppression
est en O(1).
La figure suivante nous confirme que la suppression n’est en O(1) que si α= O(1). En effet, nous pouvons
voir qu’une fois que le nombre d’´el´ements d´epasse le nombre de place, la vitesse de suppression augmente
proportionnellement au facteur de chargement. La suppression est dans ce cas en O(1+α)
Figure 3: Vitesse de suppression de 3000 ´el´ements dans un tableau de 103 places
4

3.2 Vitesse d’insertion et de suppression dans une table avec gestion de collision
par adressage ouvert (double hachage)
3.2.1 Insertion
Dans la figure 4, nous pouvons constater que le temps d’insertion grandit avec le load factor. On peut en
d´eduire qu’il est en lien avec le nombre de sondages `a effectuer avant de trouver une place, qui lui-mˆeme
augmente avec le load factor. En effet, ce graphe `a l’allure de la fonction 1
αln 1 1−αcorrespondant `a l’esp´erance
du nombre de sondage pour une recherche.
Figure 4: Vitesse d’insertion de 128 ´el´ements dans un tableau de 128 places
3.2.2 Suppression
La suppression ne d´epend pas du load factor au moment de la suppression, mais de celui au moment o`u la
cl´e `a ´et´e ins´er´ee. En effet, si nous supprimons les cl´es du tableau de mani`ere al´eatoire (ce qui est le plus
proche de conditions r´eelles), la tendance du graphique est quelconque (voir figure ??). Par contre, si nous
enlevons les cl´es dans l’ordre o`u ils ont ´et´e ins´er´es, on retrouve l’inverse du graphe d’insertion (voir figure
5). En effet, les premiers ins´er´es l’ont ´et´e rapidement, grˆace `a un load factor faible, seront les premiers `a
ˆetre supprim´es, et donc le seront ´egalement rapidement, et ce malgr´e un load factor ´egal `a un.
Figure 5: Vitesse de suppression de 128 ´el´ements dans un tableau de 128 places
5