Complexité d'exécution de la table de hachage (insertion, recherche et suppression)
Pourquoi est-ce que je vois toujours différentes complexités d'exécution pour ces fonctions sur une table de hachage?
Sur wiki, rechercher et supprimer sont O(n) (je pensais que l’intérêt des tables de hachage était d’avoir une recherche constante, quel est l’intérêt si la recherche est effectuée sur O (n)).
Dans certaines notes de cours d'il y a quelque temps, je vois un large éventail de complexités dépendant de certains détails, dont une avec tous les O (1). Pourquoi utiliser une autre implémentation si je peux obtenir tout O (1)?
Si j'utilise des tables de hachage standard dans un langage tel que C++ ou Java, à quoi dois-je m'attendre de la complexité temporelle?
Les tableaux de hachage sont O(1) moyens et amortis complexité du cas Cependant, il souffre de la complexité temporelle de O(n). [Et je pense que c'est là que se trouve votre confusion]
Les tables de hachage souffrent de la plus complexe complexité temporelle de O(n) pour deux raisons:
- Si trop d'éléments ont été hachés dans la même clé: regarder à l'intérieur de cette clé peut prendre du temps
O(n). - Une fois qu'une table de hachage a passé son équilibre de charge - elle doit réorganiser [créer une nouvelle table plus grande et réinsérer chaque élément dans la table].
Cependant, on dit qu'il s'agit d'un cas moyen et amorti de O(1) parce que:
- Il est très rare que de nombreux éléments soient hachés sur la même clé [si vous choisissez une bonne fonction de hachage et que vous n'avez pas un équilibre de charge trop important.
- L'opération de rehash, qui est
O(n), peut tout au plus se produire aprèsn/2, Qui sont toutes supposéesO(1): Ainsi, lorsque vous additionnez le temps moyen par opération, vous obtenez:(n*O(1) + O(n)) / n) = O(1)
Notez qu'en raison du problème de réémaillage - les applications en temps réel et les applications nécessitant une faible latence - ne doivent pas utiliser une table de hachage comme structure de données.
EDIT: Annoter un problème avec les tables de hachage: cache
Un autre problème pouvant entraîner une perte de performances dans les tables de hachage volumineuses est lié aux performances du cache. Les tables de hachage souffrent de mauvaises performances de cache , et donc pour une collection volumineuse, le temps d'accès peut être plus long, car vous devez recharger la partie pertinente de la table. de la mémoire dans le cache.
Idéalement, une table de hachage est O(1). Le problème est que si deux clés ne sont pas égales, elles aboutissent au même hachage.
Par exemple, imaginez les chaînes ("c'était le meilleur des cas c'était le pire des temps" et "Green Eggs and Ham" les deux ont abouti à une valeur de hachage de 123.
Lorsque la première chaîne est insérée, elle est placée dans le compartiment 123. Lorsque la deuxième chaîne est insérée, une valeur existe déjà pour le compartiment 123. Il comparerait alors la nouvelle valeur à la valeur existante et constaterait qu'elles ne sont pas égales. Dans ce cas, un tableau ou une liste liée est créé pour cette clé. À ce stade, l'extraction de cette valeur devient O(n), car la table de hachage doit parcourir chaque valeur de ce compartiment pour trouver celle qui est souhaitée.
Pour cette raison, lors de l'utilisation d'une table de hachage, il est important d'utiliser une clé avec une très bonne fonction de hachage qui est à la fois rapide et ne génère pas souvent des valeurs en double pour différents objets.
Avoir un sens?
Certaines tables de hachage ( hachage de couco ) ont garanti O(1) lookup
Peut-être que vous regardiez la complexité de l'espace? C'est O (n). Les autres complexités sont comme prévu sur l'entrée table de hachage . La complexité de la recherche approche O(1) à mesure que le nombre de compartiments augmente. Si, dans le pire des cas, vous n’avez qu’un compartiment dans la table de hachage, la complexité de la recherche est alors O (n).
Modifier en réponse au commentaire Je ne pense pas qu'il soit correct de dire O(1) est le cas moyen C'est vraiment (comme le dit la page wikipedia) O (1 + n/k) où K est la taille de la table de hachage. Si K est assez grand, alors le résultat est effectivement O 1. Bien que K soit 10 et N est 100. Dans ce cas, chaque compartiment contiendra en moyenne 10 entrées, le temps de recherche n’est donc certainement pas O (1); il s’agit d’une recherche linéaire allant jusqu’à 10 entrées.
Cela dépend de la manière dont vous implémentez le hachage. Dans le pire des cas, il peut aller à O (n), dans le meilleur des cas, il est 0(1) (généralement vous pouvez obtenir si DS n'est pas si gros facilement)