Avl ağacı üzerinde kırmızı siyah ağaç

112

AVL ve Kırmızı siyah ağaçların her ikisi de düğümlerdeki Kırmızı ve siyah renk dışında kendi kendini dengeliyor. AVL ağaçları yerine kırmızı siyah ağaçları seçmenin ana nedeni nedir? Kırmızı siyah ağaçların uygulamaları nelerdir?

algorithm data-structures red-black-tree

— Suren
kaynak

2

olası kopyası std :: map neden kırmızı-siyah ağaç olarak uygulanıyor?

— Lior Kogan

1

Bir kenara, Rust geliştiricileri , standart sıralı haritaları için bunlardan biri yerine bir B-ağacı kullanmayı seçtiler .

— Tom Anderson

126

AVL ağaçları yerine kırmızı siyah ağaçları seçmenin ana nedeni nedir?

Hem kırmızı-siyah ağaçlar hem de AVL ağaçları en sık kullanılan dengeli ikili arama ağaçlarıdır ve garantili olarak ekleme, silme ve aramayı desteklerler O(logN) time. Bununla birlikte, ikisi arasında aşağıdaki karşılaştırma noktaları vardır:

AVL ağaçları daha katı bir şekilde dengelenmiştir ve bu nedenle daha hızlı arama sağlar. Bu nedenle arama yoğun bir görev için bir AVL ağacı kullanın.
İnsert yoğun görevler için Kırmızı-Siyah ağaç kullanın.
AVL ağaçları, her düğümde denge faktörünü depolar. Bu O(N)fazladan yer kaplar. Ancak, ağaca eklenecek anahtarların her zaman sıfırdan büyük olacağını bilirsek, kırmızı-siyah bir ağacın renk bilgisini saklamak için anahtarların işaret bitini kullanabiliriz. Böylelikle bu gibi durumlarda kırmızı-siyah ağaç fazladan yer kaplamaz.

Kırmızı siyah ağacın uygulaması nedir?

Kırmızı-siyah ağaçlar daha genel amaçlıdır. Ekleme, kaldırma ve arama işlemlerinde nispeten iyi performans gösterirler, ancak AVL ağaçlarının daha yavaş ekleme / çıkarma pahasına daha hızlı aramaları vardır. Kırmızı-siyah ağaç şu şekilde kullanılır:

Java: java.util.TreeMap,java.util.TreeSet
C ++ STL (çoğu uygulamada): harita, çoklu harita, çoklu ayar
Linux çekirdeği: tamamen adil zamanlayıcı, linux / rbtree.h

— Nikunj Banka
kaynak

43

In general, the rotations for an AVL tree are harder to implement and debug than that for a Red-Black tree.doğru değil.

— Jingguo Yao

9

Bilgiçlikçi olmak gerekirse, C ++ standardı bunu zorunlu kılmaz std:: mapve arkadaşlar herhangi bir belirli yapıyı kullanır. Libstdc ++ ve Dinkumware en azından kırmızı-siyah ağaçları kullansa da, bu uygulamaya bırakılmıştır ve pratikte haklısınız gibi görünüyor.

— mbozzi

25

Bir AVL ağacının her bir düğümünde depolanan denge faktörü iki bittir (-1 / 0 / +1). Kırmızı-siyah bir ağaç, her düğümde bir bit renk bilgisi depolar. Dolayısıyla, toplamda her iki ağaç da ekstra bilgi için O (N) belleğe ihtiyaç duyar.

— Seppo Enarvi

5

"Eklemeli yoğun görevler için Kırmızı-Siyah ağaç kullanın." Neden? AVL ağaç ekleme en kötü durumda yalnızca bir dönüş alırken, Kırmızı Siyah ağaç iki tane alabilir.

— Daniel

3

Bu, Ben Pfaff'ın 2003 BST performansı analizine göre güncellenmelidir - AVL ağaçları daha genel amaçlıdır ve daha iyi performans gösterir. Java, C ++ ve Linux çekirdeğinin daha yavaş uygulamayı seçmesinin kesin tarihsel nedenlerini izlemek ilginç olacaktır.

— David McManamon

16

Bu makaleyi okumayı deneyin

Farklılıklar, benzerlikler, performans vb. Hakkında bazı iyi bilgiler sunar.

İşte makaleden bir alıntı:

RB-Ağaçları, AVL ağaçlarının yanı sıra kendi kendini dengeliyor. Her ikisi de O (log n) arama ve ekleme performansı sağlar.

Aradaki fark, RB-Trees'in uç işlemi başına O (1) dönüşü garanti etmesidir. Gerçek uygulamalardaki performansın maliyeti aslında budur.

Basitleştirilmiş RB-Trees, dinamik düğüm yapılarının yükünü taşımadan kavramsal olarak 2-3 ağaç olmaktan bu avantajı elde eder. Fiziksel olarak RB-Ağaçlar ikili ağaçlar olarak uygulanır, kırmızı / siyah bayraklar 2-3 davranışı simüle eder

Benim anlayışıma göre, AVL ağaçları ve RB ağaçları performans açısından çok uzakta değiller. Bir RB ağacı, basitçe bir B-ağacının bir çeşididir ve dengeleme, bir AVL ağacından farklı bir şekilde uygulanır.

— Ürdün
kaynak

1

AFIAK, bir AVL ağacının ayrıca ekleme başına O (1) dönüşü vardır. RB-ağacı ve AVL için - bir eklemenin 1 veya 0 dönüşü olabilir. Döndürme olursa, algoritmalar durur. Olmazsa, genellikle, algoritmalar ağacın altından köküne kadar düğümleri kontrol etmeye / yeniden boyamaya devam eder. Bu nedenle, bazen O (1) dönüşü daha iyi olabilir çünkü kalan öğeler O (log (n)) taramasını ortadan kaldırır. AVL ağacı ortalama olarak daha fazla dönüş yaptığından, AVL ağacı genellikle ~ 1.44 log (N) RB-tree 2 log (N) den daha iyi dengeye sahiptir.

— Sergey Shandar

4

Performanstaki farklılıklar hakkındaki anlayışımız yıllar içinde gelişti ve şimdi AVL yerine kırmızı-siyah ağaçları kullanmanın ana nedeni, belki de CLRS kapsamında yer almadıkları için biraz daha az yaygın oldukları için iyi bir AVL uygulamasına erişememek olurdu.

Her iki ağaç da artık sıra dengeli ağaç türleri olarak kabul ediliyor, ancak kırmızı-siyah ağaçlar gerçek dünya testlerinde sürekli olarak yaklaşık% 20 oranında daha yavaş . Veya sıralı veri eklendiğinde % 30-40 daha yavaş .

Bu nedenle kırmızı-siyah ağaçları inceleyen, ancak AVL ağaçları olmayan insanlar kırmızı-siyah ağaçları seçme eğilimindedir. Kırmızı-siyah ağaçların birincil kullanımları , onlar için Wikipedia girişinde ayrıntılı olarak açıklanmıştır .

— David McManamon
kaynak

1

Komik! Okumamda, libavl makalesi AVL ve RB'nin bire bir olduğunu ve genel olarak hiçbirinin diğerinden çok açık bir şekilde daha iyi olmadığını söylüyor gibi görünüyor (hangisinin daha iyi olduğu iş yüküne bağlıdır). AVL'nin genel olarak yaklaşık% 20 daha hızlı olduğu iddiasını hiçbir yerde görmüyorum.

— Stefan

3

Buradaki diğer cevaplar, RB ve AVL ağaçlarının artılarını ve eksilerini iyi özetliyor, ancak bu farkı özellikle ilginç buldum:

AVL ağaçları sabit amorti edilmiş güncelleme maliyetini desteklemez [ancak kırmızı-siyah ağaçlar destekler]

Kaynak: Mehlhorn & Sanders (2008) (bölüm 7.4)

RB ve AVL ağaçları hem garanti ederken Yani, O (log (N)) araması, ekin ve silme, AVL / RB mülklerinin restorasyonundan sorumlu en kötü durum zaman sonra bir düğüm ekleme veya silme O yapılabilir (1) zaman amorti için kırmızı-siyah ağaçlar.

— emanek
kaynak

AVL ağaç ekleme işleminin aynı / benzer amorti edilmiş maliyete sahip olduğuna inanıyorum, ancak daha dengeli ağaç üretiyor (1.44log (N) ve 2log (N)). Aynı zamanda, AVL ağacındaki silme işlemi daha fazla dönüş gerektirebilir. IMHO, bu WAVL en.wikipedia.org/wiki/WAVL_tree

— Sergey Shandar

1

Programcılar genellikle dinamik olarak bellek ayırmayı sevmezler. Avl ağacının sorunu, "n" elemanlar için ağacın yüksekliğini saklamak için en az log2 (log2 (n)) ... (yükseklik-> log2 (n)) bitlerine ihtiyaç duymanızdır! Bu nedenle, muazzam verileri işlerken, her bir düğümde yüksekliği depolamak için kaç bit ayırmanız gerektiğinden emin olamazsınız.

Örneğin yüksekliği depolamak için 4 baytlık int (32 bit) kullanırsanız. Maksimum yükseklik 2 ^ 32 olabilir ve bu nedenle ağaçta saklayabileceğiniz maksimum öğe sayısı 2 ^ (2 ^ 32) - (çok büyük görünüyor ama bu veri çağında sanırım hiçbir şey çok büyük değil). Bu nedenle, bu sınırı aşarsanız, yüksekliği depolamak için dinamik olarak daha fazla alan ayırmanız gerekir.

Bu bana mantıklı gelen, üniversitemdeki bir profesör tarafından önerilen bir cevap! Umarım mantıklıdır.

Düzenlemeler: AVL ağaçları, Kırmızı Siyah Ağaçlara kıyasla daha dengelidir, ancak ekleme ve silme sırasında daha fazla dönüşe neden olabilirler. Dolayısıyla, uygulamanız çok sık ekleme ve silme içeriyorsa, o zaman Kırmızı Siyah ağaçlar tercih edilmelidir. Ekleme ve silme işlemleri daha seyrekse ve arama daha sık çalışıyorsa, AVL ağacı Kırmızı Siyah Ağaç yerine tercih edilmelidir. - Kaynak GEEKSFORGEEKS.ORG

— Prakhar Agrawal
kaynak

1

Bunun ilginç ama pratik olmadığını söyleyebilirim. En kompakt durumda, yükseklik için tahsis edilecek en verimli bit sayısını seçmenin zor olduğu doğru olsa da, pratikte bir bayttan daha az kalan herhangi bir alan kesinlikle kullanılmayacak ve kalan her şey kalacaktır . 4 veya hatta 8 baytlık bir alanda neredeyse kesinlikle kullanılmayacaktır. Bellek, performans nedenlerinden ötürü hizalanmamış olarak tahsis edilmemiştir, bu da küçük miktarda alanı geri kazanmanın yararını büyük ölçüde geçersiz kılar. Çocuklara işaretçiler ve değer 24 bayt kaplar; 8 tanesinin daha pratik maliyeti olması olası değildir.

— Mumbleskates

4

you need need atleast log2(log2(n))...(height->log2(n)) bits to store the height of [an AVL] treeBunu uygulamak için bir AVL ağacındaki herhangi bir düğümün yüksekliğine ihtiyacım yok. Her düğüm için bir bitlik ekstra bilgi alırsınız ( EN BÜYÜK BENİM (en yüksek alt ağaca sahip kardeş)); AV & L tarafından sunulduğu gibi iki ekstra bitin olması geleneksel olduğu kadar daha kullanışlıdır (çocuk sol ve sağ için daha yüksektir)

— greybeard

4

2 ^ (2 ^ 32) element çoktur ... tüm evrendeki her bir molekülü ve bu moleküllerin olası her çiftini ve mümkün olan her üçlüyü depolayabileceğiniz ve yine de uzaktan bile yaklaşmaya başlayamayacağınız gibi. bu sayının küplü kökünün küçük bir yüzdesinin küçük bir kesri içinde olması yüz kentilyona bölünür.

— noktalı virgül

4

Bu çok yanıltıcıdır. İlk olarak, yüksekliği bir AVL ağacının bir düğümünde saklamamız gerekmez. İkincisi, yapmış olsak ve tipik kullanılabilir bellek miktarı her yıl iki katına çıksa bile, ağaçlarımızın yüksekliği 32 bitte saklanabilenleri aşana kadar 4 milyar yılımız var.

— Gassa

3

2 ^ (2 ^ 32) nesneler gülünç bir şekilde, delice, kesinlikle şu anda tasavvur edebileceğimiz herhangi bir bilgisayarın tutabileceğinden daha fazlasıdır. 2 ^ 40 gibi bir şeydeyiz. Matematik olup olmadığınızı tekrar kontrol edin.

— Stefan Reich

-1

AVL ağacının yeniden dengelenmesi aşağıdaki özelliği karşılamalıdır. (Wiki Referansı - AVL Ağacı )

Bir AVL ağacında, herhangi bir düğümün iki alt ağacının yükseklikleri en fazla bir farklılık gösterir; herhangi bir zamanda birden fazla farklılık gösterirlerse, bu özelliği eski haline getirmek için yeniden dengeleme yapılır.

Bu, AVL ağacının toplam yüksekliğinin deliye dönmeyeceği anlamına gelir, yani aramalar AVL Trees ile daha iyi olacaktır. Yüksekliğin delinmesine izin vermemek için ek işlemler (rotasyonlar) yapılacağından, ağaç modifikasyon işlemleri biraz maliyetli olabilir.

— Samshers
kaynak

Başka birçok yerden bahsediliyor, ancak bu cevabın çok iyi olmamasının nedeni, AVL ağaçlarının ve RB ağaçlarının son derece benzer kısıtlamaları etkin bir şekilde sürdürmeleridir - RB ağaçları, gerekli yüksekliğin 2.0 katından fazla olmayacaktır ve AVL ağaçları için bu faktör yaklaşık 1.44. Sonuç olarak AVL ağaçları biraz daha sık döner, ancak dönüş başına maliyet esasen aynıdır; pahalı değil.

— Mumbleskates