2 Table de hachage

} }

Les objets Lencapsulent une liste d’association. Les méthodes getet putemploient toutes les deux la méthode AList.getCell pour retrouver l’information associée à la clé key passée en argument. La technique de l’encapsulage est désormais familière, nous l’avons déjà exploitée pour les ensembles, les piles et les files dans les chapitres précédents.

Mais il faut surtout noter une nouveauté : la classeLdéclare implémenter l’interface Assoc (mot-cléimplements). Cette déclaration entraˆıne deux conséquences importantes.

Le compilateur Java vérifie que les objets de la classeLpossèdent bien les deux méthodes spécifiées par l’interfaceAssoc, avec les signatures conformes. Il y a un détail étrange : les méthodes spécifiées par une interface sont obligatoirement public.

Un objetLpeut prendre le type Assoc, ce qui arrive par exemple dans l’appel suivant : // in est un WordReader

count(in, new L()) ; // Compter les mots de in.

Notez quecountne connaˆıt pas la classeL, seulement l’interface Assoc.

Notre programme Freqfonctionne, mais il n’est pas très efficace. En effet si la liste d’association est de tailleN, une recherche pargetCellpeut prendre de l’ordre deN opérations, en particulier dans le cas fréquent où la clé n’est pas dans la liste. Il en résulte que le programme Freq est en O(n²) oùnest le nombre de mots de l’entrée. Pour atteindre une efficacité bien meilleure, nous allons introduire la nouvelle notion de table de hachage.

La table de hachage est une implémentation efficace de la table d’association. Appelons univers des clésl’ensembleU de toutes les clés possibles. Nous allons d’abord observer qu’il existe un cas particulier simple quand l’univers des clés est un petit intervalle entier, puis ramener le cas général à ce cas simple.

2.1 Adressage direct

Cette technique très efficace ne peut malheureusement s’appliquer que dans des cas très particuliers. Il faut que l’univers des clés soit de la forme {0, . . . , n−1}, où nest un entier pas trop grand, et d’autre part que deux éléments distincts aient des clés distinctes (ce que nous avons d’ailleurs déjà supposé). Il suffit alors d’utiliser un tableau de taille npour représenter la table d’association.

Ce cas s’applique par exemple à la base de donnée des concurrents d’une épreuve sportive qui exclut les ex-æquos. Le rang à l’arrivée d’un concurrent peut servir de clé dans la base de données. Mais, ne nous leurrons pas un cas aussi simple est exceptionnel en pratique. Le fait pertinent est de remarquer que le problème de la recherche d’information se simplifie beaucoup quand les clés sont des entiers pris dans un petit intervalle.

2.2 Table de hachage

L’idée fondamentale de la table de hachage est de se ramener au cas de l’adressage direct, c’est-à-dire de clés qui sont des indices dans un tableau. Soit m, entier pas trop grand, à vrai dire entier de l’ordre du nombre d’éléments d’informations que l’on compte gérer. On se donne une fonction

h:U → {0, . . . , m−1}

appelée fonction de hachage. L’idée est de ranger l’élément de clé k non pas dans une case de tableau t[k], comme dans l’adressage direct (cela n’a d’ailleurs aucun sens si k n’est pas un entier) , mais dans t[h(k)]. Nous reviendrons en 3 sur le choix, relativement délicat, de la fonction de hachage. Mais nous devons affronter dès à présent une difficulté. En effet, il devient déraisonnable d’exclure le cas de clés (distinctes) k et k^′ telles que h(k) = h(k^′). La figure 1 illustre la survenue d’une telle collision entre les clés k₁ et k₃ distinctes qui sont telles que h(k₁) =h(k₃). Précisons un peu le problème, supposons que la collision survient lors de l’ajout

Fig.1 – Une collision dans une table de hachage.

0 1

de l’élément d’information v₃ de clé k₃, alors qu’il existe déjà dans la table une clé k₁ avec h(k₁) =h(k₃). La question est alors : où ranger l’information associée à la clék₃?

2.3 R´esolution des collisions par chaˆınage

La solution la plus simple pour résoudre les collisions consiste à mettre tous les éléments d’in-formation dont les clés ont même valeur de hachage dans une liste. On parle alors de résolution des collisions par chaˆınage. Dans le cas de l’exemple de collision de la figure 1, on obtient la situation de la figure 2. On remarque que les éléments de la tabletsont tout bêtement des listes d’association, la liste t[i]regroupant tous les éléments d’information (k, v) de la table qui sont tels que h(k) vaut l’indicei.

Nous proposons une nouvelle impl´ementation H des tables d’associationsAssoc, en encap-sulant cette fois une table de hachage.

class H implements Assoc {

final static int SIZE=1024 ; // Assez grand ?

private AList [] t ; // Tableau interne de listes d’associations.

H() { t = new AList [SIZE] } ;

private int hash(String key) { return Math.abs(key.hashCode()) % t.length ;}

Fig.2 – R´esolution des collisions par chaˆınage.

public int get(String key) { int h = hash(key) ;

AList r = AList.getCell(key, t[h]) ; i f (r == null) {

public void put(String key, int val) { int h = hash(key) ;

AList r = AList.getCell(key, t[h]) ; i f (r == null) {

Le code de la fonction de hachage hash est en fait assez simple, parce qu’il utilise la méthode de hachage des chaˆınes fournie par Java (toute la complexité est cachée dans cette méthode) dont il réduit le résultat modulo la taille du tableau internet, afin de produire un indice valide.

La valeur absolue Math.abs est malheureusement nécessaire, car pour n négatif, l’opérateur ((reste de la division euclidienne)) %renvoie un résultat négatif (misère).

Il est surtout important de remarquer :

Le code est en fait presque le mˆeme que celui de la classe L(page 67), en rempla¸cant p part[h].

La classeH déclare implémenter l’interface Assoc et le fait effectivement ce que le com-pilateur vérifie. Un objet de la nouvelle classe H est donc un argument valide pour la méthode countde la classe Freq.

Estimons le coût deputet degetpour une table qui contient N éléments d’information. On suppose que le coût du calcul de la fonction hachage est enO(1), et que hachage est uniforme, c’est-à-dire que la valeur de hachage d’une clé vaut h ∈ [0. . . m[ avec une probabilité 1/m.

Ces deux hypothèses sont réalistes. Pour la première, en supposant que le coût de calcul de la fonction de hachage est proportionnel à la longueur des mots, nous constatons que la longueur des mots d’un texte ordinaire deN mots est faible et indépendante deN.²La seconde hypothèse traduit simplement que nous disposons d’une ((bonne )) fonction de hachage, faisons confiance

a la m´ethode hashCodedes String.

Sous ces deux hypothèses, la recherche d’un élément se fait en moyenne en temps Θ(1 +α), oùα=n/mest lefacteur de charge(load factor) de la table (nest le nombre de clés à ranger et m est la taille du tableau). Plus précisément une recherche infructueuse dans la table parcourt en moyenne α cellules de listes, et une recherche fructueuse 1 +α/2−1/(2m) cellules, coûts auquels on ajoute le coût du calcul de la fonction de hachage. Ce résultat est démontré dans [2, section 12.2], contentons nous de remarquer queαest tout simplement la longueur moyenne des listes d’associations t[h].

Peut-être faut il remarquer que le coût d’une recherche dans le cas le pire est O(n), quand toutes les clés entrent en collision. Mais employer les tables de hachage suppose de faire confiance au hasard (hachage uniforme) et donc de considérer plus le cas moyen que le cas le pire. Une fa¸con plus concrète de voir les choses est de considérer que, par exemple lors du comptage des mots d’un texte, on insère et recherche de nombreux mots uniformément hachés, et que donc le coût moyen donne une très bonne indication du coût rencontré en pratique.

Dans un premier temps, pour notre implémentation simple deHqui dimensionne le tableaut initialement, nous pouvons interpréter le résultat de complexité en moyenne d’une recherche en Θ(1 +α), en constatant que si la taille du tableau interne est de l’ordre de n, alors nous avons atteint un coût (en moyenne) deput etget en temps constant. Il peut sembler que nous nous sommes livrés à une suite d’approximations et d’à-peu-près, et c’est un peu vrai. Il n’en reste pas moins, et c’est le principal, que les tables de hachage sont efficaces en pratique, essentiellement sous réserve que pour une exécution donnée, les valeurs de hachage des clés se répartissent uniformément parmi les indices du tableau interne correctement dimensionné, mais aussi que le coût du calcul de la fonction de hachage ne soit pas trop élevé. Dans cet esprit pragmatique, on peut voir la table de hachage comme un moyen simple de diviser le coût des listes d’association d’un facteurn, au prix de l’allocation d’un tableau de taille de l’ordre de n.

2.3.1 Compl´ement : redimensionnement dynamique

Dans un deuxi`eme temps, il est plus convenable, et ce sera aussi plus pratique, de redi-mensionner dynamiquement la table de hachage afin de maintenir le facteur de charge dans des limites raisonnables. Pour atteindre un coˆut amorti en temps constant pourput, il suffit de deux conditions (comme pour push dans le cas des piles, voir II.2.1)

La taille des tableaux internes doit suivre une progression g´eom´etrique au cours du temps.

Le coût du redimensionnement doit être proportionnel au nombre d’informations stockées dans la table au moment de ce redimensionnement.

Définissons d’abord une constantealphaqui est notre borne supérieure du facteur de charge, et une variable d’instance nbKeysqui compte le nombre d’associations effectivement présentes dans la table.

final static double alpha = 4.0 ; private int nbKeys = 0 ;

final static int SIZE = 16 ;

2Un autre argument est de dire qu’il existe de l’ordre deN =K^ℓ mots de taille inférieure à ℓ, oùK est le nombre de caractères possibles. Dans ce cas le coût du calcul de la fonction de hachage est enO(logN), réputé indépendant denpourn≪N.

Nous avons aussi changé la valeur de la taille par défaut de la table, afin de ne pas mobiliser une quantité conséquente de mémoirea priori. C’est aussi une bonne idée de procéder ainsi afin que le redimensionnement ait effectivement lieu et que le code correspondant soit testé.

La méthode de redimensionnementresize, à ajouter à la classeHdouble la taille du tableau internet.

private void resize() {

int old_sz = t.length ; // Ancienne taille int new_sz = 2*old_sz ; // Nouvelle taille

AList [] oldT = t ; // garder une r´ef´erence sur l’ancien tableau t = new AList [new_sz] ; // Allouer le nouveau tableau

/* Ins´erer toutes les paires cl´e-information de oldT dans le nouveau tableau t */

for (int i = 0 ; i < old_sz ; i++) {

for (AList p = oldT[i] ; p != null ; p = p.next) { int h = hash(p.key) ;

t[h] = new AList (p.key, p.val, t[h]) ; }

} }

Il faut noter que la fonction de hachage hash qui transforme les clés en indices du tableau t dépend de la taille det(de fait son code emploie this.t.length). Pour cette raison, le nouveau tableau est directement rangé dans le champtde this et une référence sur l’ancien tableau est conservée dans la variable localeoldT, le temps de parcourir les paires clé-information contenues dans les listes de l’ancien tableau pour les ajouter dans le nouveau tableau t. Le redimension-nement n’est pas gratuit, il est même assez coûteux, mais il reste bien proportionnel au nombre d’informations stockées — sous réserve d’un calcul en temps constant de la fonction de hachage.

C’est la méthode putqui tient à jour le comptenbKeyet appelle le méthoderesizequand le facteur de charge nbKeys/t.length dépassealpha.

public void put(String key, int val) { int h = hash(key) ;

AList r = AList.getCell(key, t[h]) ; i f (r == null) {

t[h] = new AList(key, val, t[h]) ; nbKeys++ ;

i f (t.length * alpha < nbKeys) { resize() ;

} } else {

r.val = val ; }

}

Notez que le redimensionnement est, le cas échéant, effectuéaprès ajout d’une nouvelle associa-tion. En effet, la valeur de hachagehn’est valide que relativement à la longueur de tableaut.

2.4 Adressage ouvert

Dans le hachage à adressage ouvert, les éléments d’informations sont stockés directement dans le tableau. Plus précisément, la table de hachage est un tableau de paires clé-information.

Le facteur de charge α est donc nécessairement inférieur à un. Étant donnée une clé k on recherche l’information associée à k d’abord dans la case d’indice h(k), puis, si cette case est occupée par une information de clék^′ différente de k, on continue la recherche en suivant une

séquence d’indices prédéfinie, jusqu’à trouver une case contenant une information dont la clé vaut k ou une une case libre. Dans le premier cas il existe un élément de clé k dans la table, dans le second il n’en existe pas. La séquence la plus simple consiste à examiner successivement les indices h(k), h(k) + 1, h(k) + 2 etc. modulo m taille de la table. C’est le sondage linéaire (linear probing).

Pour ajouter une information (k, v), on procède exactement de la même manière, jusqu’à trouver une case libre ou une case contenant la paire (k, v^′). Dans les deux cas, on dispose d’une case où ranger (k, v), au besoin en écrasant la valeur v^′ anciennement associée à k. Selon cette technique, une fois entrée dans la table, une clé reste à la même place dans le tableau et est accédée selon la même séquence, à condition de ne pas supprimer d’informations, ce que nous supposons.

Pour coder une nouvelle implémentation O de la table d’association Assoc, qui utilise le hachage avec adressage ouvert. Nous définissons d’abord une classe des paires clé-information.

class Pair {

String key ; int val ;

Pair(String key, int val) { this.key = key ; this.val = val ; } }

Les objets O possèdent en propre un tableau d’objets Pair. Le code de la classe O est donné par la figure 3. Dans le constructeur, les cases du tableaunew Pair [SIZE]sont implicitement initialisées à null (voir B.3.6.2), qui est justement la valeur qui permet à getSlot d’identifier les cases (( vides )). La méthode getSlot, chargée de trouver la case où ranger une association en fonction de la clé, est appelée par les deux méthodes put et get. La relative complexité de getSlotjustifie cette organisation. La méthodegetSlotpeut échouer, quand la table est pleine

— notez l’emploi de la boucle do, voir B.3.4, ce qui rend la question du dimensionnement du tableau interne plus critique que dans le cas du chaˆınage.

Exercice 1 Modifier le code de la classeOafin de redimensionner automatiquement le tableau interne, d`es que le facteur de charge d´epasse une valeur critiquealpha.

final static double alpha = 0.5 ;

Solution.Comme dans le cas du chaˆınage, nous allons écrire une méthode privéeresizechargée d’agrandir la table quand elle devient trop chargée. La méthode putest modifiée pour gérer le compte nbKeys des informations effectivement présentes dans la table, et appeler resize si besoin est.

private int nbKeys = 0 ;

public void put(String key, int val) { int h = getSlot(key) ;

Pair p = t[h] ; i f (p == null) {

nbKeys++ ;

t[h] = new Pair(key, val) ;

i f (t.length * alpha < nbKeys) resize() ; } else {

p.val = val ; }

}

Fig.3 – Impl´ementation d’une table de hachage `a adressage ouvert class O implements Assoc {

private final static int SIZE = 1024 ; // Assez grand ? private Pair [] t ; // Tableau interne de paires O() { t = new Pair[SIZE] ; }

private int hash(String key) { return Math.abs(key.hashCode()) % t.length ; } /* Méthode de recherche de la case associée à key */

private int getSlot(String key) { int h0 = hash(key) ;

int h = h0 ; do {

/* Si t[h] est (( vide )) ou contient la cl´e key, on a trouv´e */

i f (t[h] == null || key.equals(t[h].key)) return h ; /* Sinon, passer `a la case suivante */

h++ ;

i f (h >= t.length) h = 0 ; } while (h != h0) ;

throw new Error ("Table pleine") ; // On a fait le tour complet }

public int get(String key) { Pair p = t[getSlot(key)] ; i f (p == null) {

return 0 ; } else {

return p.val ; }

}

public void put(String key, int val) { int h = getSlot(key) ;

Pair p = t[h] ; i f (p == null) {

t[h] = new Pair(key, val) ; } else {

p.val = val ; }

} }

La méthode resize fait appel à getSlot pour transférer les informations de l’ancienne à la nouvelle table. C’est le meilleur moyen de garantir des ajouts compatibles avec les méthodes putetget.

private void resize() { int old_sz = t.length ; int new_sz = 2*old_sz ; Pair [] oldT = t ; t = new Pair[new_sz] ;

for (int k = 0 ; k < old_sz ; k++) { Pair p = oldT[k] ;

i f (p != null) t[getSlot(p.key)] = p ; }

} }

Il faut, comme dans le cas du chaˆınage, prendre la pr´ecaution de ranger le nouveau tableau dans la variable d’instance t avant de commencer `a calculer les valeurs de hachage dans le nouveau tableau. On note aussi queoldT[k] peut valoir null et qu’il faut en tenir compte.

On démontre [6, section 6.4] qu’une recherche infructueuse entraˆıne en moyenne l’examen d’environ 1/2·(1 + 1/(1−α)²) cases et une recherche fructueuse d’environ 1/2·(1 + 1/(1−α)), où α est le facteur de charge et sous réserve de hachage uniforme. Ces résultats ne sont stricto sensu plus valables pourα proche de un, mais les formules donnent toujours un majorant. Bref, pour un facteur de charge de 50 % on examine en moyenne pas plus de trois cases.

Le sondage linéaire provoque des phénomènes de regroupement (en plus des collisions).

Consid´erons par exemple la table ci-dessous, o`u les cases encore libres sont en blanc :

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 0

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

En supposant queh(k) soit distribué uniformément, la probabilité pour que la caseisoit choisie

a la prochaine insertion est la suivante

P(0) = 1/19 P(2) = 2/19 P(3) = 1/19 P(8) = 5/19 P(9) = 1/19 P(12) = 3/19 P(13) = 1/19 P(14) = 1/19 P(16) = 2/19 P(18) = 2/19 Comme on le voit, la case 8 a la plus grande probabilité d’être occupée, ce qui accentuera le le regroupement des cases 4–7. Ce phénomène se révèle rapidement quand des clés successives sont hachées sur des entiers successifs, un cas qui se présente en pratique avec le hachage modulo (voir 3), quand les clés sont par exemple les valeurs successives d’un compteur, ou, dans des applications plus techniques, des adresses d’objets qui se suivent dans la mémoire.

Plusieurs solutions ont été proposées pour éviter ce problème. La meilleure solution consiste

a utiliser un double hachage. On se donne deux fonctions de hachageh:U → {0, . . . , m−1} et h^′ :U → {1, . . . , r−1} (r < m). Ensuite le sondage est effectué selon la séquence h(k) +h^′(k), h(k) + 2h^′(k), h(k) + 3h^′(k), etc. Les regroupements ne sont plus à craindre essentiellement parce que l’incrément de la séquence est lui aussi devenu une fonction uniforme de la clé. En particulier en cas de collision selon h, il n’y a aucune raison que les sondages se fassent selon le même incrément. Pour que le sondage puisse parcourir toute la table on prend h^′(k) >0 et h^′(k) premier avec m taille de la table. Pour ce faire on peut prendre m égal à une puissance de deux eth^′(k) toujours impair, ou mpremier eth^′(k) strictement inférieur à m(par exemple pour des clé entièresh(k) =kmodmet h^′(k) = 1 + (kmod (m−2))

Dans [6, section 6.4] D. Knuth montre que, sous des hypoth`eses de distribution uniforme et d’ind´ependance des deux fonctions de hachage, le nombre moyen de sondages pour un hachage

double est environ −ln(1−α)/α en cas de succès et à 1/(1−α) en cas d’échec.³ Le tableau ci-dessous donne quelques valeurs numériques :

Facteur de charge 50 % 80 % 90 % 99 %

Succ`es 1.39 2.01 2.56 4.65

Echec 2.00 5.00 10.00 100.00

Comme on le voitα = 80 % est un excellent compromis. Insistons sur le fait que les valeurs de ce tableau sont indépendantes de n. Par conséquent, avec un facteur charge de 80 %, il suffit en moyenne de deux essais pour retrouver un élément, même avec dix milliards de clés ! Notons que pour le sondage linéaire cet ordre de grandeur est atteint pour des tables à moitié pleines.

Tandis que pour le chaˆınage on peut aller jusqu’`a un facteur de charge d’environ 4.

En fixant ces valeurs de facteur de charge pour les trois techniques, nous égalisons plus ou moins les temps de recherche. Examinons alors la mémoire occupée pour n associations.

Nous constatons que le chaˆınage consomme un tableau de taille n/4 plus n cellules de listes à trois champs, soit 3 +n/4 + 5·n cases de mémoire en Java, en tenant compte de deux cases supplémentaires par objet (voir II.4). Tandis que le sondage linéaire consomme 3 + 2·n+ 4·n

Dans le document Cours programmation et algorithmique – Cours et formation gratuit (Page 68-78)