Applications des arbres rouge-noir
Quelles sont les applications des arbres rouge-noir (RB)? Existe-t-il une application où seuls les arbres RB peuvent être utilisés et aucune autre structure de données?
Un arbre rouge-noir est une implémentation particulière d'un arbre de recherche binaire auto-équilibré , et aujourd'hui il semble être le choix d'implémentation le plus populaire.
Arbres de recherche binaires sont utilisés pour implémenter des cartes finies, où vous stockez un ensemble de clés avec des valeurs associées. Vous pouvez également implémenter des ensembles en utilisant uniquement les clés et en ne stockant aucune valeur.
L'équilibrage de l'arborescence est nécessaire pour garantir de bonnes performances, sinon l'arborescence pourrait dégénérer en liste, par exemple si vous insérez des clés déjà triées.
L'avantage des arbres de recherche par rapport aux tables de hachage est que vous pouvez parcourir efficacement l'arbre dans l'ordre de tri.
AVL-arbres sont une autre variante des arbres de recherche binaires équilibrés. Ils étaient populaires avant que les arbres rouge-noir ne soient connus. Ils sont plus soigneusement équilibrés, avec une différence maximale de un entre les hauteurs du sous-arbre gauche et droit (les arbres RB garantissent au plus un facteur deux). Leur principal inconvénient est que le rééquilibrage demande plus d'efforts.
Les arbres rouge-noir sont donc certainement un bon choix mais pas le seul pour cette application.
Les arbres rouges noirs appartiennent à une classe de BST à équilibrage automatique et, comme d'autres l'ont répondu, un tel arbre à équilibrage automatique peut être utilisé. Je voudrais ajouter que les arbres rouge-noir sont largement utilisés comme tables de symboles système. Par exemple, ils sont utilisés pour implémenter les éléments suivants:
- Java: Java.util.TreeMap, Java.util.TreeSet.
- C++ STL: carte, multimap, multiset.
- Noyau Linux: planificateur complètement équitable, linux/rbtree.h
Sauf si vous avez des exigences de performances très spécifiques, une arborescence R-B peut être remplacée par une autre arborescence binaire auto-équilibrée, par exemple une arborescence AVL. Le choix entre les deux est essentiellement une optimisation des performances - ils offrent les mêmes opérations de base.
Non pas que l'un d'eux soit définitivement "plus rapide" que l'autre, mais simplement qu'ils sont suffisamment différents pour que leurs utilisations spécifiques aient tendance à avoir des performances légèrement différentes, toutes choses étant égales par ailleurs. Donc, si vous dessinez vos exigences avec suffisamment de soin, ou tout simplement par hasard, vous pourriez vous retrouver avec l'un d'eux "assez rapide" pour votre usage, et l'autre non. R-B offre une insertion légèrement plus rapide que AVL, au prix d'une recherche légèrement plus lente.
Il n'y a pas de règle comme le rouge noir ne peut être utilisé que dans un cas particulier, cela dépend de l'application dans des cas comme lorsque vous devez créer l'arborescence une seule fois et que vous devez l'interroger plusieurs fois, vous pouvez opter pour une arborescence AVL car dans l'arborescence AVL, la recherche est assez rapide. Mais elle est strictement équilibrée, de sorte que l'insertion et la suppression peuvent prendre un certain temps. Fair Scheduler utilisé dans les noyaux Linux actuels depuis quelques jours.
les contraintes appliquées sur l'arbre rouge noir renforcent également le fait que le chemin de la racine à la feuille la plus éloignée n'est pas plus de deux fois plus long que le chemin de la racine à la feuille la plus proche.
BTW, vous pouvez rechercher les différents temps de recherche et d'insertion, etc. requis pour un arbre rouge noir ici
Average Worst case
Space O(n) O(n)
Search O(log n) O(log n)
Insert O(log n) O(log n)
Delete O(log n) O(log n)