2010-01-10 9 views
4

Les arbres de recherche binaires randomisés comme treap donnent une bonne performance (de l'ordre de O (log n)) avec une probabilité élevée tout en évitant les opérations de rééquilibrage compliquées (et coûteuses) nécessaires aux arbres déterministes équilibrés comme AVL, red-blackm, AA, etc.arbres de recherche binaires randomisés

Nous savons que si nous ajoutons des clés aléatoires à un simple BST, nous pouvons nous attendre à ce qu'il soit raisonnablement équilibré. Une raison simple est que le nombre d'arbres lourdement non équilibrés pour n nœuds est beaucoup plus faible que le nombre d'arbres «presque équilibrés» et donc, un ordre aléatoire pour l'insertion des clés est susceptible de se retrouver avec un arbre acceptable. Dans ce cas, dans «L'art de la programmation par ordinateur», Knuth donne un peu plus de 1,3 * lg2 (n) que la longueur moyenne d'un chemin qui est plutôt bon. Il dit aussi que en supprimant une clé aléatoire de l'arbre aléatoire préserve son caractère aléatoire (et donc son bon équilibrage moyen).

Il semble donc qu'un arbre de recherche binaire dans lequel les clés sont insérées et supprimées dans un ordre aléatoire donnerait probablement des performances de l'ordre de O (log n) pour les trois opérations: recherche, insertion et suppression.

Cela dit, je me demande si l'approche suivante donnerait les mêmes bonnes propriétés:

  • prendre une fonction de hachage h (x) qui est connu pour être « bon » (par exemple, il assurer une répartition homogène de les touches)
  • utilisez la commande définie par h (x) sur les touches au lieu de la commande sur k.
  • en cas de collision, commander en fonction de la clé. Cela devrait être rare si la clé de hachage est assez bonne et la gamme de la fonction de hachage est beaucoup plus grande que l'ensemble des touches.

Pour donner un exemple, un BST pour la touche {4, 3, 5, 1, 2} inséré dans cet ordre, serait:

    4 
       /\ 
       3 5 
       /\ 
       1 2 

En supposant que la fonction de hachage serait les associer à (respectivement) {221,142,12,380,18) nous aurions.

    221(4) 
       / \ 
       142(3) 380(1) 
      / \ 
      12(5) 18(2) 

Le point clé est que BST peut dégénérer « régulière » car les touches sont insérées selon la même relation de commande qui est utilisé pour les stocker dans l'arbre (leur ordre « naturel », par exemple l'ordre alphabétique de la chaîne) mais la fonction de hachage induit un ordre sur les clés qui n'a aucun rapport avec le caractère "naturel" et, par conséquent, devrait donner les mêmes résultats que si les clés étaient insérées dans un ordre aléatoire.

Une hypothèse forte est que la fonction de hachage est "bonne", mais ce n'est pas déraisonnable, je pense.

Je n'ai trouvé aucune référence à une approche similaire dans la littérature, donc cela pourrait être complètement faux, mais je ne vois pas pourquoi!

Voyez-vous un inconvénient dans mon raisonnement? Quelqu'un a déjà essayé de le faire?

Répondre

5

Je pense que ce que vous suggérez est de simplement ordonner en utilisant des valeurs de hachage, en comptant sur la propagation des valeurs de hachage pour un arbre équilibré. Cela fonctionne, et il devrait vous donner des arbres correctement équilibrés dans la pratique avec une bonne fonction de hachage.

La raison pour laquelle nous ne voyons pas d'autres personnes utilisant quelque chose comme ceci, IMO, est que si vous commandez par fonction de hachage, votre structure de données n'est plus triée. Oui, il est toujours trié par fonction de hachage, mais l'élément avec la plus petite fonction de hachage n'est généralement pas l'élément que vous auriez besoin de chercher, alors que les recherches comme le plus petit/plus grand/kème élément sont souvent utiles. Étant donné que la structure de données n'a plus cette propriété, il est beaucoup plus logique d'avoir une table de hachage qui utilise la fonction de hachage pour stocker dans un tableau pour obtenir des performances O (1) au lieu de O (log n).

0

N'est-ce pas une façon de stocker une table de hachage?

2

Cela me semble raisonnable. Avez-vous cherché pour voir si cela a déjà été formalisé ou au moins noté?

En ce qui concerne les inconvénients: je suppose une objection possible serait: si vous avez déjà payé le prix pour l'exécution d'une fonction de hachage pourquoi ne pas simplement utiliser une table de hachage «

Une objection connexe est que vous avez?. déjà lié la complexité temporelle aux propriétés de distribution de la fonction de hachage, dans ce cas l'arbre n'ajoute pas beaucoup sur une table de hachage J'aime les arbres mais les tables de hachage sont généralement plus rapides Cela signifie que le principal avantage de l'arbre haché est qu'il utilise la gamme complète de la fonction de hachage tandis que la table de hachage en jette une grande partie dans le module op

0

il utilise généralement quelque chose comme un arbre B pour le stockage, ce qui est généralement assez similaire à la façon dont le hachage extensible fonctionne. Et oui, cela fonctionne généralement très bien.

Questions connexes