ต้นไม้สีแดงดำเหนือต้นไม้ avl

116

ต้นไม้ AVL และ Red black มีความสมดุลในตัวเองยกเว้นสีแดงและสีดำในโหนด อะไรคือเหตุผลหลักในการเลือกต้นไม้สีแดงดำแทนต้นไม้ AVL? ต้นไม้ดำแดงใช้งานอะไรได้บ้าง?

algorithm  data-structures  red-black-tree 
— แน่ใจ
แหล่งที่มา
2
— Lior Kogan
1
ในทางกลับกันผู้พัฒนา Rust เลือกที่จะใช้B-treeแทนที่จะใช้อย่างใดอย่างหนึ่งสำหรับแผนที่ตามลำดับมาตรฐานของพวกเขา
— ทอมแอนเดอร์สัน

คำตอบ:

128

อะไรคือเหตุผลหลักในการเลือกต้นไม้สีแดงดำแทนต้นไม้ AVL?

ทั้งต้นแดงดำและต้น AVLมีใช้กันมากที่สุดต้นไม้ค้นหาแบบทวิภาคที่สมดุลO(logN) timeและพวกเขาสนับสนุนการแทรกการลบและการมองขึ้นในการรับประกัน อย่างไรก็ตามมีจุดเปรียบเทียบระหว่างสองสิ่งต่อไปนี้:

  • ต้นไม้ AVL มีความสมดุลมากขึ้นและทำให้การค้นหาเร็วขึ้น ดังนั้นสำหรับงานที่ต้องค้นหาอย่างเข้มข้นให้ใช้ทรี AVL
  • สำหรับงานที่ต้องใช้การแทรกมากให้ใช้ต้นไม้สีแดง - ดำ
  • ต้นไม้ AVL เก็บปัจจัยสมดุลที่แต่ละโหนด ใช้O(N)พื้นที่เพิ่ม อย่างไรก็ตามหากเรารู้ว่าคีย์ที่จะใส่ในทรีจะมีค่ามากกว่าศูนย์เสมอเราสามารถใช้บิตเครื่องหมายของคีย์เพื่อเก็บข้อมูลสีของต้นไม้สีแดงดำได้ ดังนั้นในกรณีเช่นนี้ต้นไม้สีแดง - ดำจึงไม่ต้องใช้พื้นที่เพิ่ม

ต้นไม้ดำแดงใช้อะไรได้บ้าง?

ต้นไม้สีแดงดำมีวัตถุประสงค์ทั่วไปมากกว่า พวกเขาทำได้ค่อนข้างดีในการเพิ่มลบและค้นหา แต่ต้นไม้ AVL มีการค้นหาที่เร็วกว่าโดยมีค่าใช้จ่ายในการเพิ่ม / ลบที่ช้าลง ต้นไม้สีแดง - ดำใช้ในสิ่งต่อไปนี้:

  • Java: java.util.TreeMap,java.util.TreeSet
  • C ++ STL (ในการใช้งานส่วนใหญ่): map, multimap, multiset
  • เคอร์เนลลินุกซ์: ตัวกำหนดตารางเวลาที่ยุติธรรมอย่างสมบูรณ์ linux / rbtree.h
— Nikunj Banka
แหล่งที่มา
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
27
ปัจจัยสมดุลที่เก็บไว้ในแต่ละโหนดของทรี AVL คือสองบิต (-1 / 0 / +1) ต้นไม้สีแดง - ดำเก็บข้อมูลสีหนึ่งบิตในแต่ละโหนด ดังนั้นโดยรวมทั้งสองต้นไม้จึงต้องการหน่วยความจำ O (N) สำหรับข้อมูลเพิ่มเติม
— Seppo Enarvi
7
"สำหรับงานที่ต้องใช้การแทรกมากให้ใช้ต้นไม้สีแดง - ดำ" ทำไม? การแทรกต้นไม้ AVL จะหมุนเพียงครั้งเดียวที่แย่ที่สุดในขณะที่ต้นไม้สีแดงดำสามารถใช้เวลาได้สองครั้ง
— Daniel
3
สิ่งนี้ควรได้รับการอัปเดตตามการวิเคราะห์ประสิทธิภาพ BST ของ Ben Pfaff ในปี 2546 - ต้นไม้ AVL มีวัตถุประสงค์ทั่วไปมากกว่าและทำงานได้ดีกว่า เหตุผลทางประวัติศาสตร์ที่แน่นอนสำหรับ Java, C ++ และเคอร์เนล Linux ที่เลือกการใช้งานที่ช้ากว่านั้นน่าสนใจที่จะติดตาม
— David McManamon
16

ลองอ่านเรื่องนี้ บทความนี้

มีข้อมูลเชิงลึกที่ดีเกี่ยวกับความแตกต่างความคล้ายคลึงประสิทธิภาพและอื่น ๆ

นี่คือคำพูดจากบทความ:

RB-Trees เป็นเช่นเดียวกับต้นไม้ AVL ที่ปรับสมดุลในตัวเอง ทั้งสองให้ประสิทธิภาพการค้นหาและการแทรก O (log n)

ความแตกต่างคือ RB-Trees รับประกันการหมุน O (1) ต่อการใช้งานเม็ดมีด นั่นคือสิ่งที่คุ้มค่ากับประสิทธิภาพในการใช้งานจริง

แบบง่าย RB-Trees ได้เปรียบนี้จากการมีแนวคิดเป็นต้นไม้ 2-3 ต้นโดยไม่ต้องแบกรับโครงสร้างโหนดแบบไดนามิก RB-Trees ทางกายภาพถูกนำไปใช้เป็นต้นไม้ไบนารีธงสีแดง / ดำจำลองพฤติกรรม 2-3 อย่าง

เท่าที่ความเข้าใจของฉันไปต้น AVL และต้นไม้ RB นั้นไม่ไกลกันมากในแง่ของประสิทธิภาพ ต้นไม้ RB เป็นเพียงตัวแปรของ B-tree และการปรับสมดุลจะถูกนำไปใช้แตกต่างจากต้นไม้ AVL

— จอร์แดน
แหล่งที่มา
2
AFIAK ต้นไม้ AVL ยังมีการหมุน O (1) ต่อการแทรก สำหรับ RB-tree และ AVL การแทรกหนึ่งครั้งอาจมีการหมุน 1 หรือ 0 ครั้ง หากการหมุนเกิดขึ้นอัลกอริทึมจะหยุดลง หากไม่เกิดขึ้นโดยปกติอัลกอริทึมจะตรวจสอบ / ทาสีโหนดจากด้านล่างไปยังรากของต้นไม้ต่อไป ดังนั้นบางครั้งการหมุน O (1) อาจดีกว่าเนื่องจากจะกำจัดการสแกนรายการที่เหลือ O (log (n)) เนื่องจากโดยเฉลี่ยแล้วต้นไม้ AVL ทำให้เกิดการหมุนมากขึ้นต้นไม้ AVL จึงมีความสมดุลที่ดีกว่า ~ 1.44 log (N) มากกว่า RB-tree 2 log (N)
— Sergey Shandar
5

ความเข้าใจของเราเกี่ยวกับความแตกต่างในประสิทธิภาพได้ดีขึ้นในช่วงหลายปีที่ผ่านมาและตอนนี้เหตุผลหลักที่ต้องใช้ต้นไม้สีแดงดำบน AVL คือไม่สามารถเข้าถึงการใช้งาน AVL ที่ดีได้เนื่องจากพบได้น้อยกว่าเล็กน้อยบางทีอาจเป็นเพราะไม่ครอบคลุมใน CLRS

ต้นไม้ทั้งสองได้รับการพิจารณาในขณะนี้รูปแบบของต้นไม้ยศสมดุลแต่ต้นไม้สีแดงสีดำมีอย่างต่อเนื่องช้าลงโดยประมาณ 20% ในการทดสอบในโลกแห่งความจริง หรือแม้กระทั่ง 30-40% ช้าเมื่อข้อมูลตามลำดับจะถูกแทรก

ดังนั้นคนที่ศึกษาต้นไม้สีแดงดำ แต่ไม่ใช่ต้นไม้ AVL มักจะเลือกต้นไม้สีแดงดำ การใช้หลักสำหรับต้นไม้สีแดงสีดำมีรายละเอียดในรายการวิกิพีเดียสำหรับพวกเขา

— เดวิดแมคมานามอน
แหล่งที่มา
1
ตลก! ในการอ่านของฉันบทความ libavl ดูเหมือนจะบอกว่า AVL และ RB เป็นแบบตัวต่อตัวและก็ไม่ได้ดีไปกว่ากันโดยทั่วไปอย่างชัดเจน (อันไหนดีกว่าขึ้นอยู่กับปริมาณงาน) ฉันไม่เห็นที่ใดที่อ้างว่า AVL โดยรวมเร็วขึ้นประมาณ 20%
— Stefan
4

คำตอบอื่น ๆ สรุปข้อดีข้อเสียของต้นไม้ RB และ AVL ได้ดี แต่ฉันพบว่าความแตกต่างนี้น่าสนใจเป็นพิเศษ:

ต้นไม้ AVL ไม่รองรับต้นทุนการอัปเดตที่ตัดจำหน่ายคงที่[แต่ต้นไม้สีแดง - ดำทำ]

ที่มา: Mehlhorn & Sanders (2008) (หัวข้อ 7.4)

ดังนั้นในขณะที่ทั้ง RB และ AVL ทรีรับประกัน O (log (N)) เวลาที่เลวร้ายที่สุดสำหรับการค้นหาแทรกและลบการกู้คืนคุณสมบัติ AVL / RB หลังจากแทรกหรือลบโหนดสามารถทำได้ใน O (1) เวลาที่ตัดจำหน่ายสำหรับ ต้นไม้สีแดงดำ

— อีมาเน็ก
แหล่งที่มา
1
ฉันเชื่อว่าการแทรกต้นไม้ AVL มีต้นทุนตัดจำหน่ายที่เท่ากัน / ใกล้เคียงกัน แต่สร้างต้นไม้ที่สมดุลได้ดีกว่า (1.44log (N) เทียบกับ 2log (N)) ในเวลาเดียวกันการลบในทรี AVL อาจต้องมีการหมุนเวียนมากขึ้น IMHO มีการระบุไว้ใน WAVL en.wikipedia.org/wiki/WAVL_tree
— Sergey Shandar
0

โดยทั่วไปโปรแกรมเมอร์ไม่ชอบที่จะจัดสรรหน่วยความจำแบบไดนามิก ปัญหาเกี่ยวกับต้นไม้ avl คือสำหรับองค์ประกอบ "n" คุณต้องมีอย่างน้อย log2 (log2 (n)) ... (height-> log2 (n)) บิตเพื่อเก็บความสูงของต้นไม้! ดังนั้นเมื่อคุณจัดการข้อมูลมหาศาลคุณจึงไม่สามารถแน่ใจได้ว่าจะจัดสรรกี่บิตสำหรับการจัดเก็บความสูงในแต่ละโหนด

ตัวอย่างเช่นถ้าคุณใช้ int 4 ไบต์ (32 บิต) เพื่อจัดเก็บความสูง ความสูงสูงสุดคือ: 2 ^ 32 และด้วยเหตุนี้จำนวนองค์ประกอบสูงสุดที่คุณสามารถจัดเก็บในต้นไม้ได้คือ 2 ^ (2 ^ 32) - (ดูเหมือนจะใหญ่มาก แต่ในยุคนี้ของข้อมูลไม่มีอะไรใหญ่เกินไปฉันเดา) และด้วยเหตุนี้หากคุณยิงเกินขีด จำกัด นี้คุณจะต้องจัดสรรพื้นที่เพิ่มเติมสำหรับการจัดเก็บความสูงแบบไดนามิก

นี่คือคำตอบที่อาจารย์ในมหาวิทยาลัยของฉันแนะนำซึ่งดูสมเหตุสมผลสำหรับฉัน! หวังว่าฉันจะเข้าใจ

การแก้ไข: ต้นไม้ AVL มีความสมดุลมากกว่าเมื่อเทียบกับ Red Black Trees แต่อาจทำให้เกิดการหมุนมากขึ้นระหว่างการแทรกและการลบ ดังนั้นหากแอปพลิเคชันของคุณเกี่ยวข้องกับการแทรกและการลบบ่อยครั้งต้นไม้สีแดงดำควรเป็นที่ต้องการ และหากการแทรกและการลบมีความถี่น้อยลงและการค้นหามีการดำเนินการบ่อยกว่าควรเลือกต้นไม้ AVL เหนือต้นไม้สีแดงดำ - แหล่งที่มา GEEKSFORGEEKS.ORG

— ปราฆรอักราวัล
แหล่งที่มา
1
ฉันจะบอกว่าสิ่งนี้น่าสนใจ แต่ทำไม่ได้ แม้ว่าในกรณีที่กะทัดรัดที่สุดจะเป็นงานที่ยากในการเลือกจำนวนบิตที่มีประสิทธิภาพสูงสุดเพื่อจัดสรรความสูง แต่ในทางปฏิบัติพื้นที่ที่เหลือน้อยกว่าหนึ่งไบต์จะไม่ถูกใช้อย่างแน่นอนและสิ่งที่เหลืออยู่ ในพื้นที่ขนาด 4 หรือ 8 ไบต์แทบจะไม่ได้ใช้งานเลย หน่วยความจำไม่ได้รับการจัดสรรอย่างไม่ตรงแนวด้วยเหตุผลด้านประสิทธิภาพซึ่งแทนที่ประโยชน์ของการเรียกคืนพื้นที่เพียงเล็กน้อย พอยน์เตอร์ไปยังเด็ก ๆ และค่าครอบครอง 24 ไบต์ อีก 8 อย่างไม่น่าจะมีต้นทุนจริง
— Mumbleskates
4
you need need atleast log2(log2(n))...(height->log2(n)) bits to store the height of [an AVL] treeฉันไม่ต้องการความสูงของโหนดใด ๆ ในต้นไม้ AVL เพื่อใช้งาน คุณต้องการข้อมูลเพิ่มเติมหนึ่งบิตสำหรับแต่ละโหนด ( ฉันคือคนที่ยิ่งใหญ่ที่สุด (พี่น้องที่มีต้นไม้ย่อยสูงสุด))); สะดวกกว่าเช่นเดียวกับแบบธรรมดาที่จะมีบิตพิเศษสองตัว (เด็กสูงกว่าสำหรับซ้ายและขวา) ตามที่ AV & L. นำเสนอ
— greybeard
4
2 ^ (2 ^ 32) องค์ประกอบมีมาก ... เช่นเดียวกับที่คุณสามารถเก็บทุกโมเลกุลในจักรวาลทั้งหมดและโมเลกุลที่เป็นไปได้ทุกคู่และทุก ๆ สามที่เป็นไปได้และยังไม่เริ่มเข้ามาใกล้ระยะไกลด้วยซ้ำ อยู่ภายในเศษเสี้ยวเล็ก ๆ ของรูทที่ถูกลูกบาศก์ของจำนวนนั้นหารด้วยหนึ่งร้อย quintillion
— อัฒภาค
4
นี่เป็นเรื่องที่ทำให้เข้าใจผิดมาก ขั้นแรกเราไม่จำเป็นต้องเก็บความสูงไว้ในโหนดของต้นไม้ AVL ประการที่สองแม้ว่าเราจะทำเช่นนั้นและแม้ว่าจำนวนหน่วยความจำที่มีอยู่โดยทั่วไปจะเพิ่มขึ้นเป็นสองเท่าทุก ๆ ปี แต่เราก็ยังมีเวลาอีก 4 พันล้านปีจนกว่าความสูงของต้นไม้ของเราจะเกินกว่าที่เก็บได้ใน 32 บิต
— กัซซ่า
3
2 ^ (2 ^ 32) วัตถุเป็นสิ่งที่น่าขันอย่างบ้าคลั่งมากกว่าคอมพิวเตอร์ทุกเครื่องที่เราสามารถจินตนาการได้ในตอนนี้ เราอยู่ที่ 2 ^ 40 ตรวจสอบคุณคณิตศาสตร์อีกครั้ง
— Stefan Reich
-1

การปรับสมดุลของต้นไม้ AVL ควรเป็นไปตามคุณสมบัติด้านล่าง (อ้างอิงวิกิ - ทรี AVL )

ในแผนภูมิ AVL ความสูงของต้นไม้ย่อยสองลูกของโหนดใด ๆ จะแตกต่างกันอย่างมาก หากเมื่อใดก็ตามที่มีความแตกต่างกันมากกว่าหนึ่งรายการจะทำการปรับสมดุลใหม่เพื่อกู้คืนคุณสมบัติ

ดังนั้นนี่จึงหมายความว่าความสูงโดยรวมของต้นไม้ AVL ไม่สามารถทำให้บ้าได้เช่นการค้นหาจะดีกว่าด้วย AVL Trees และเนื่องจากต้องมีการดำเนินการเพิ่มเติม (การหมุน) เพื่อไม่ให้ความสูงมากไปการดำเนินการปรับเปลี่ยนต้นไม้อาจมีราคาแพงเล็กน้อย

— samshers
แหล่งที่มา
มีการกล่าวถึงสถานที่อื่น ๆ อีกมากมาย แต่เหตุผลที่คำตอบนี้ไม่ดีนักคือต้นไม้ AVL และต้นไม้ RB รักษาข้อ จำกัด ที่คล้ายกันอย่างมีประสิทธิภาพ - ต้นไม้ RB จะมีความสูงไม่เกิน 2.0 เท่าของความสูงที่ต้องการและสำหรับต้นไม้ AVL นั้นปัจจัยคือ ประมาณ 1.44. ต้นไม้ AVL หมุนบ่อยขึ้นเล็กน้อยเป็นผลให้ แต่ต้นทุนต่อการหมุนนั้นเท่ากัน มันไม่แพง
— Mumbleskates
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.