Comment éviter les redimensionnements en cascade lors du redimensionnement des tables de hachage?

Avec les méthodes conventionnelles de résolution des collisions comme le chaînage séparé et le palpage linéaire / quadratique, la séquence de palpage pour une clé peut être arbitrairement longue - elle est simplement maintenue courte avec une probabilité élevée en gardant le facteur de charge de la table bas. Les collisions lors du remaillage ne sont donc pas un problème car elles n'affectent pas le facteur de charge.

Cependant, avec le hachage de coucou (et d'autres méthodes offrant le pire temps de recherche O (1)?), Un redimensionnement doit se produire lorsque la séquence de sonde d'une clé devient trop longue. Mais lorsque les clés sont mélangées pendant le remaniement, il se peut qu'elles créent une séquence de sonde trop longue pour une clé, nécessitant un autre redimensionnement - éventuellement plusieurs, si cela se produit plusieurs fois de suite. La probabilité est faible, surtout avec une bonne fonction de hachage, mais je l'ai vu se produire.

Existe-t-il un moyen - à moins de générer explicitement une fonction de hachage parfaite pendant le rehash - de garantir que les redimensionnements ne peuvent pas se dérouler en cascade de cette manière? Peut-être spécifique à un schéma de résolution de collision donné? La littérature que j'ai rencontrée jusqu'ici semble occulter entièrement la question. Gardez à l'esprit que je souhaite également réduire les tables de hachage, pas seulement les agrandir.

Vous demandez comment éviter les retouches en cascade, mais vous avez déjà donné la réponse dans votre message. Vous gardez faible la probabilité que de mauvais événements se produisent.

Puisque vous mentionnez le hachage du coucou. La probabilité d'obtenir une longue séquence de sondage est$O(1/n^2)$. Donc, si vous ressassiez, vous insérez$n$éléments à partir de zéro. La probabilité que la reprise ne réussisse pas est alors$O(1/n)$, donc avec une très forte probabilité que vous réussissiez. Dans l'attente, vous n'avez besoin que d'un nombre constant d'essais. Si vous constatez que vous rencontrez des problèmes lors du ré-hachage, vous devez augmenter la taille de votre table et modifier votre facteur de charge. Vous pouvez également sélectionner une meilleure famille de fonctions de hachage.

Je pense avoir une solution, inspirée du hachage linéaire :

Si la ou les fonctions de hachage sont maintenues constantes (c'est-à-dire qu'elles ne sont pas modifiées lors du redimensionnement) et que la table est toujours agrandie en doublant les emplacements, puis une fois la table agrandie, elle considère que

$H \mod 2L = \begin{cases} H \mod L + L & \text{or} \\ H \mod L \end{cases}$

où $H$est le hachage d'une clé et est l'ancien nombre d'emplacements. Cela signifie qu'une clé reste où elle est ou se déplace vers un emplacement unique dans la zone nouvellement allouée, qui est garantie d'être vide.$L$

Pour appliquer cela au hachage de coucou (d-ary), redimensionnez simplement chacune des sous-tables individuellement et ne déplacez pas les clés entre les sous-tables.

Pour réduire le tableau, vous devez confirmer que l'un des est vacant pour chaque clé de la table, et si c'est le cas, déplacez-les tous vers leurs emplacements . Bien sûr, c'est ... Je ne sais pas s'il y a une meilleure façon de le faire que d'exécuter la vérification pour chaque suppression une fois que le facteur de charge tombe en dessous de la moitié.$\lbrace H \mod \frac{L}{2} + \frac{L}{2}, ~ H \mod \frac{L}{2} \rbrace$$H \mod \frac{L}{2}$$O(n)$