Червоне чорне дерево над avl дерево


108

AVL та Червоні чорні дерева одночасно балансують, за винятком Червоного та Чорного кольору у вузлах. Яка головна причина вибору Червоних чорних дерев замість дерев AVL? Які додатки Червоних чорних дерев?



1
В сторону розробники Rust вирішили використовувати B-дерево замість будь-якого з них для своєї стандартної впорядкованої карти.
Том Андерсон

Відповіді:


123

Яка головна причина вибору Червоних чорних дерев замість дерев AVL?

Як червоно-чорні дерева, так і AVL-дерева є найбільш часто використовуваними збалансованими деревами бінарного пошуку, і вони підтримують гарантію вставки, видалення та пошуку O(logN) time. Однак є наступні моменти порівняння між ними:

  • Дерева AVL більш жорсткі і збалансовані, а отже, забезпечують швидший огляд. Таким чином, для інтенсивного пошуку задачі використовуйте дерево AVL.
  • Для вставки інтенсивних завдань використовуйте червоно-чорне дерево.
  • Дерева AVL зберігають коефіцієнт балансу на кожному вузлі. Це займає O(N)додаткове місце. Однак якщо ми знаємо, що ключі, які будуть вставлені у дерево, завжди будуть більшими за нуль, ми можемо використовувати бітові знаки клавіш для зберігання кольорової інформації червоно-чорного дерева. Таким чином, у таких випадках червоно-чорне дерево не займає зайвого місця.

Яке застосування Червоного чорного дерева?

Червоно-чорні дерева мають більш загальне призначення. Вони відносно добре додають, видаляють та шукають, але дерева AVL мають більш швидкі пошуки за рахунок повільнішого додавання / видалення. Червоно-чорне дерево використовується в наступному:

  • Java: java.util.TreeMap,java.util.TreeSet
  • C ++ STL (у більшості реалізацій): карта, мультимапа, мультисети
  • Ядро Linux: повністю справедливий планувальник, linux / rbtree.h

43
In general, the rotations for an AVL tree are harder to implement and debug than that for a Red-Black tree.неправда.
Jingguo Yao

9
Щоб бути педантичним, стандарт C ++ не вимагає цього std:: mapі друзі використовують якусь конкретну структуру. Це залишається за реалізацією, хоча libstdc ++ та Dinkumware принаймні використовує червоно-чорні дерева, і, здається, ви праві на практиці.
mbozzi

25
Коефіцієнт балансу, що зберігається у кожному вузлі дерева AVL, становить два біти (-1 / 0 / +1). Червоно-чорне дерево зберігає по одному біту кольорової інформації у кожному вузлі. Таким чином, в цілому обидва дерева потребують O (N) пам'яті для отримання додаткової інформації.
Seppo Enarvi

5
"Для вставки інтенсивних завдань використовуйте червоно-чорне дерево." Чому? Вставлення AVL-дерева займає лише один обертання в гіршому випадку, тоді як червоне чорне дерево може приймати два.
Даніель

3
Це слід оновити відповідно до аналізу Ben Bfa Pfaff 2003 року щодо продуктивності BST - дерева AVL мають загальне призначення та краще. Точні історичні причини для Java, C ++ та ядра Linux, що обирають повільнішу реалізацію, було б цікавим.
Девід Мак-Манамон

16

Спробуйте прочитати цю статтю

Він пропонує корисну інформацію про відмінності, схожість, ефективність тощо.

Ось цитата зі статті:

RB-Дерева, як і дерева AVL, самоврівноважуються. Обидва вони забезпечують ефективність пошуку O (log n) та вставки.

Різниця полягає в тому, що RB-Дерева гарантують обертання O (1) за операцію вставки. Саме це фактично коштує продуктивності в реальних реалізаціях.

Спрощено, RB-Дерева отримують цю перевагу, оскільки концептуально вони складають 2-3 дерева, не переносячи накладні динамічні структури вузлів. Фізично RB-дерева реалізуються як бінарні дерева, червоні / чорні прапори імітують 2-3 поведінки

Що стосується мого власного розуміння, дерева AVL та дерева RB не дуже далекі в плані продуктивності. Дерево RB - це просто варіант B-дерева, і врівноваження реалізується інакше, ніж дерево AVL.


1
AFIAK, дерево AVL також має обертання O (1) на вставку. Для дерева RB та AVL - одна вставка може мати 1 або 0 обертів. Якщо відбувається обертання, алгоритми зупиняються. Якщо цього не відбувається, алгоритми продовжують перевіряти / перефарбовувати вузли знизу до кореня дерева. Отже, іноді обертання O (1) може бути кращим, оскільки воно виключає сканування решти елементів O (log (n)). Оскільки дерево AVL, в середньому, робить більше обертання, дерево AVL, як правило, має кращий баланс ~ 1,44 log (N), ніж RB-дерево 2 log (N).
Сергій Шандар

4

Наше розуміння відмінностей у продуктивності покращилось з роками, і тепер основною причиною використання червоно-чорних дерев над AVL було б відсутність доступу до гарної реалізації AVL, оскільки вони є дещо рідшими, можливо, тому що вони не охоплені CLRS.

Обидва дерева зараз вважаються формами збалансованих за рангом дерев, але червоно-чорні дерева послідовно повільніше приблизно на 20% у реальних тестах світу . Або навіть на 30-40% повільніше при введенні послідовних даних .

Тож люди, які вивчали червоно-чорні дерева, але не AVL-дерева, як правило, обирають червоно-чорні дерева. Основні напрямки використання червоно-чорних дерев детально описані у Вікіпедії .


1
Смішно! в моєму читанні, стаття про libavl, здається, говорить про те, що AVL та RB - це голова до голови, і жодна з них не є явно кращою, ніж інша в цілому (яка з них краще залежить від навантаження). Я ніде не бачу твердження, що AVL загалом на 20% швидше.
Стефан

3

Інші відповіді тут добре підсумовують плюси та мінуси дерев RB та AVL, але ця різниця мені здається особливо цікавою:

Дерева AVL не підтримують постійну амортизовану вартість оновлення [але червоно-чорні дерева]

Джерело: Mehlhorn & Sanders (2008) (розділ 7.4)

Отже, хоча і RB, і AVL дерева гарантують O (log (N)) найгірший час для пошуку, вставлення та видалення, відновлення властивості AVL / RB після вставки або видалення вузла може бути здійснено за O (1) амортизований час для червоно-чорні дерева.


Я вважаю, що вставка дерева AVL має однакову / схожу амортизовану вартість, але створює краще збалансоване дерево (1,44log (N) проти 2log (N)). У той же час, для видалення в дереві AVL може знадобитися більше обертів. ІМХО, це питання розглядається в WAVL en.wikipedia.org/wiki/WAVL_tree
Сергій Шандар

1

Програмісти зазвичай не люблять динамічно розподіляти пам'ять. Проблема дерева avl полягає в тому, що для елементів "n" вам потрібні найменші біти log2 (log2 (n)) ... ... (висота-> log2 (n)), щоб зберігати висоту дерева! Отже, обробляючи величезні дані, ви не можете бути впевнені, скільки біт відведено для зберігання висоти на кожному вузлі.

Наприклад, якщо ви використовуєте 4 байти int (32 біта) для зберігання висоти. Максимальна висота може бути: 2 ^ 32 і, отже, Максимальна кількість елементів, які ви можете зберігати у дереві, становить 2 ^ (2 ^ 32) - (здається, дуже велика, але в цьому віці даних нічого не занадто великого, мабуть). Отже, якщо ви перевищуєте цю межу, вам доведеться динамічно виділяти більше місця для зберігання висоти.

Це відповідь, запропонована професором мого університету, яка мені здавалася розумною! Сподіваюся, я маю сенс.

Правки: дерева AVL є більш врівноваженими порівняно з червоними чорними деревами, але вони можуть викликати більше обертання під час вставки та видалення. Отже, якщо ваша заявка передбачає численні часті вставки та видалення, слід віддати перевагу червоним чорним деревам. І якщо вставки та видалення рідші, а пошук частіший, то слід віддати перевагу дереву AVL над Червоним Чорним деревом. --Джерело GEEKSFORGEEKS.ORG


1
Я б сказав, що це цікаво, але непрактично. Хоча це правда, що в найбільш компактному випадку складно буде вибрати найбільш ефективну кількість біт для розподілу за висотою, але на практиці будь-який залишений простір, менший за байт, точно не буде використаний, і все, що залишилося у просторі 4 або навіть 8 байт майже напевно залишиться невикористаним. Пам'ять не виділяється нерівномірно з міркувань продуктивності, що значно переважає на користь повернення невеликої кількості місця. Покажчики на дітей і значення займають 24 байти; Ще 8 навряд чи матимуть практичну вартість.
Мамочка

4
you need need atleast log2(log2(n))...(height->log2(n)) bits to store the height of [an AVL] treeМені не потрібна висота жодного вузла в AVL-дереві для його реалізації. Вам потрібен один біт додаткової інформації для кожного вузла ( Я ВЕЛИКИЙ (брат та сестра з найвищим під-деревом))); зручніше, як і звичайно, мати два зайвих біта (дитина вище для лівих та правих), як це представлено AV & L.
сіра борода

4
2 ^ (2 ^ 32) елементів - це багато ... як ви могли б зберігати кожну окрему молекулу у всьому Всесвіті, і кожну можливу пару цих молекул, і кожну можливу трійку, і досі навіть не починати надходити навіть віддалено близько знаходячись у крихітній частці крихітного відсотка кубикового кореня цього числа, поділеного на сто квінтиліона.
крапка з комою

4
Це дуже вводить в оману. По-перше, нам не потрібно зберігати висоту у вузлі дерева AVL. По-друге, навіть якщо ми це зробили, і навіть якщо типовий об'єм пам’яті щороку збільшується вдвічі, у нас все ще залишається 4 мільярди років, поки висота наших дерев перевищить те, що можна зберігати в 32 біти.
Гасса

3
2 ^ (2 ^ 32) об'єктів є смішно, шалено, абсолютно більше, ніж будь-який комп'ютер, який ми можемо передбачити зараз. Ми на щось схоже на 2 ^ 40. Перевірте, що ви знову математика.
Стефан Рейх

-1

Перебалансування дерева AVL повинно відповідати наведеному нижче властивості. (Довідник Wiki - дерево AVL )

У дереві AVL висота двох дочірніх підрядів будь-якого вузла відрізняється щонайменше на одну; якщо в будь-який час вони відрізняються більш ніж одним, для відновлення цієї властивості робиться перебалансування.

Отже, це означає, що загальна висота дерева AVL не може зійти з розуму, тобто пошуки стануть кращими для AVL Дерев. Оскільки додаткові операції (обертання) потрібно робити, щоб висота не зійшла з розуму, операції з модифікації дерева можуть бути дорогими.


Згадується багато інших місць, але причина цієї відповіді не дуже хороша в тому, що дерева AVL та дерева RB ефективно підтримують надзвичайно подібні обмеження - дерева RB не перевищуватимуть 2,0 разу більше необхідної висоти, а для дерев AVL цей фактор є близько 1,44. Дерева AVL обертаються дещо частіше, як наслідок, але ціна за ротацію по суті однакова; це не дорого.
Мамочка
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.