Tại sao std :: map được triển khai dưới dạng cây đỏ-đen?

Tại sao được std::mapthực hiện như một cây đỏ-đen ?

Có một số cây tìm kiếm nhị phân cân bằng (BST) ngoài kia. Thiết kế đánh đổi trong việc chọn cây đỏ đen là gì?

Có lẽ hai thuật toán cây tự cân bằng phổ biến nhất là cây Đỏ-Đen và cây AVL . Để cân bằng cây sau khi chèn / cập nhật cả hai thuật toán, sử dụng khái niệm xoay trong đó các nút của cây được xoay để thực hiện cân bằng lại.

Mặc dù trong cả hai thuật toán, các thao tác chèn / xóa là O (log n), trong trường hợp xoay vòng cân bằng lại cây Đỏ-Đen là thao tác O (1) trong khi với AVL, đây là thao tác O (log n) , thực hiện Cây Đỏ-Đen hiệu quả hơn trong khía cạnh này của giai đoạn cân bằng lại và một trong những lý do có thể khiến nó được sử dụng phổ biến hơn.

Cây đỏ-đen được sử dụng trong hầu hết các thư viện bộ sưu tập, bao gồm các dịch vụ từ Java và Microsoft .NET Framework.

Nó thực sự phụ thuộc vào cách sử dụng. Cây AVL thường có nhiều vòng quay tái cân bằng. Vì vậy, nếu ứng dụng của bạn không có quá nhiều thao tác chèn và xóa, nhưng nặng về tìm kiếm, thì cây AVL có lẽ là một lựa chọn tốt.

std::map sử dụng cây Đỏ-Đen vì nó có sự đánh đổi hợp lý giữa tốc độ chèn / xóa nút và tìm kiếm.

Cây AVL có chiều cao tối đa 1,44logn, trong khi cây RB có tối đa 2logn. Chèn một phần tử trong AVL có thể ngụ ý sự cân bằng tại một điểm trên cây. Việc tái cân bằng kết thúc việc chèn. Sau khi chèn một chiếc lá mới, việc cập nhật tổ tiên của chiếc lá đó phải được thực hiện đến tận gốc, hoặc đến một điểm mà hai cây con có độ sâu bằng nhau. Xác suất phải cập nhật k nút là 1/3 ^ k. Cân bằng lại là O (1). Loại bỏ một yếu tố có thể ngụ ý nhiều hơn một sự cân bằng lại (tối đa một nửa độ sâu của cây).

Cây RB là cây B của bậc 4 được biểu thị dưới dạng cây tìm kiếm nhị phân. Một nút 4 trong cây B dẫn đến hai cấp độ trong BST tương đương. Trong trường hợp xấu nhất, tất cả các nút của cây là 2 nút, chỉ có một chuỗi 3 nút xuống một chiếc lá. Lá đó sẽ ở khoảng cách 2logn từ gốc.

Đi xuống từ gốc đến điểm chèn, người ta phải thay đổi 4 nút thành 2 nút, để đảm bảo mọi thao tác chèn sẽ không bão hòa một chiếc lá. Quay trở lại từ việc chèn, tất cả các nút này phải được phân tích để đảm bảo chúng đại diện chính xác cho 4 nút. Điều này cũng có thể được thực hiện đi xuống trong cây. Chi phí toàn cầu sẽ như nhau. Không có bữa trưa miễn phí đâu! Loại bỏ một yếu tố khỏi cây là theo cùng một thứ tự.

Tất cả các cây này yêu cầu các nút mang thông tin về chiều cao, cân nặng, màu sắc, v.v ... Chỉ các cây Splay không có thông tin bổ sung như vậy. Nhưng hầu hết mọi người đều sợ cây Splay, vì sự tàn bạo trong cấu trúc của chúng!

Cuối cùng, cây cũng có thể mang thông tin trọng lượng trong các nút, cho phép cân bằng trọng lượng. Đề án khác nhau có thể được áp dụng. Người ta phải cân bằng lại khi một cây con chứa hơn 3 lần số phần tử của cây con khác. Cân bằng lại được thực hiện một lần nữa hoặc xoay vòng một hoặc hai lần. Điều này có nghĩa là một trường hợp xấu nhất của 2,4logn. Người ta có thể thoát ra với 2 lần thay vì 3, tỷ lệ tốt hơn nhiều, nhưng điều đó có thể có nghĩa là để lại ít hơn 1% số cây con không cân bằng ở đây và đó. Khó khăn!

Loại cây nào là tốt nhất? AVL chắc chắn. Chúng là mã đơn giản nhất và có chiều cao xấu nhất gần nhất để đăng nhập. Đối với cây có 1000000 phần tử, AVL sẽ có chiều cao tối đa 29, RB 40 và trọng lượng cân bằng 36 hoặc 50 tùy theo tỷ lệ.

Có rất nhiều biến số khác: tính ngẫu nhiên, tỷ lệ thêm, xóa, tìm kiếm, v.v.

Các câu trả lời trước chỉ giải quyết các lựa chọn thay thế cây và màu đen đỏ có lẽ chỉ còn lại vì lý do lịch sử.

Tại sao không phải là bảng băm?

Một loại chỉ yêu cầu <toán tử (so sánh) được sử dụng làm khóa trong cây. Tuy nhiên, các bảng băm yêu cầu mỗi loại khóa có một hashhàm được xác định. Giữ các yêu cầu loại ở mức tối thiểu là rất quan trọng đối với lập trình chung để bạn có thể sử dụng nó với nhiều loại và thuật toán khác nhau.

Thiết kế một bảng băm tốt đòi hỏi kiến ​​thức sâu sắc về bối cảnh mà nó sẽ được sử dụng. Nó nên sử dụng địa chỉ mở, hoặc chuỗi liên kết? Những mức tải nào nên chấp nhận trước khi thay đổi kích thước? Nó có nên sử dụng một hàm băm đắt tiền để tránh va chạm, hay một thứ thô và nhanh?

Vì STL không thể lường trước đâu là lựa chọn tốt nhất cho ứng dụng của bạn, nên mặc định cần phải linh hoạt hơn. Cây "chỉ hoạt động" và quy mô độc đáo.

(C ++ 11 đã thêm các bảng băm với unordered_map. Bạn có thể thấy từ tài liệu mà nó yêu cầu thiết lập các chính sách để định cấu hình nhiều tùy chọn này.)

Còn những cây khác thì sao?

Cây Đỏ Đen cung cấp tra cứu nhanh và tự cân bằng, không giống như các BST. Một người dùng khác đã chỉ ra những ưu điểm của nó so với cây AVL tự cân bằng.

Alexander Stepanov (Người tạo ra STL) nói rằng anh ta sẽ sử dụng Cây B * thay vì cây Đỏ-Đen nếu anh ta viết std::maplại, vì nó thân thiện hơn với bộ nhớ đệm hiện đại.

Một trong những thay đổi lớn nhất kể từ đó là sự phát triển của cache. Việc bỏ lỡ bộ nhớ cache rất tốn kém, vì vậy địa phương tham chiếu quan trọng hơn nhiều bây giờ. Các cấu trúc dữ liệu dựa trên nút, có địa phương tham chiếu thấp, có ý nghĩa ít hơn nhiều. Nếu tôi thiết kế STL ngày hôm nay, tôi sẽ có một bộ container khác. Ví dụ, B * -tree trong bộ nhớ là lựa chọn tốt hơn nhiều so với cây đỏ đen để thực hiện một thùng chứa kết hợp. - Alexander Stepanov

Bản đồ có nên sử dụng cây xanh?

Một triển khai bản đồ có thể khác sẽ là một vectơ được sắp xếp (sắp xếp chèn) và tìm kiếm nhị phân. Điều này sẽ hoạt động tốt đối với các container không được sửa đổi thường xuyên nhưng được truy vấn thường xuyên. Tôi thường làm điều này trong C như qsortvà bsearchđược xây dựng trong.

Tôi thậm chí có cần sử dụng bản đồ?

Cân nhắc bộ nhớ cache có nghĩa là hiếm khi có ý nghĩa để sử dụng std::listhoặc std::dequehơn std:vectorngay cả đối với những tình huống chúng tôi được dạy ở trường (chẳng hạn như xóa một yếu tố khỏi giữa danh sách). Áp dụng lý do tương tự, sử dụng vòng lặp for để tìm kiếm tuyến tính một danh sách thường hiệu quả và sạch sẽ hơn so với việc xây dựng bản đồ cho một vài tra cứu.

Tất nhiên việc chọn một container có thể đọc được thường quan trọng hơn hiệu suất.

Cập nhật 2017-06-2014: webbertiger chỉnh sửa câu trả lời sau khi tôi nhận xét. Tôi nên chỉ ra rằng câu trả lời của nó bây giờ tốt hơn rất nhiều đối với mắt tôi. Nhưng tôi vẫn giữ câu trả lời của mình như thông tin bổ sung ...

Do thực tế là tôi nghĩ rằng câu trả lời đầu tiên là sai (sửa: không phải cả hai nữa) và thứ ba có một khẳng định sai. Tôi cảm thấy mình phải làm rõ mọi chuyện ...

Hai cây phổ biến nhất là AVL và Red Black (RB). Sự khác biệt chính nằm ở việc sử dụng:

• AVL: Tốt hơn nếu tỷ lệ tham vấn (đọc) lớn hơn thao tác (sửa đổi). In chân bộ nhớ ít hơn một chút so với RB (do bit cần thiết để tô màu).
• RB: Tốt hơn trong các trường hợp chung khi có sự cân bằng giữa tham vấn (đọc) và thao tác (sửa đổi) hoặc sửa đổi nhiều hơn so với tham vấn. Dấu chân bộ nhớ lớn hơn một chút do lưu trữ cờ đỏ-đen.

Sự khác biệt chính đến từ màu sắc. Bạn có ít hành động cân bằng lại trong cây RB hơn AVL vì việc tô màu cho phép bạn đôi khi bỏ qua hoặc rút ngắn các hành động cân bằng lại có chi phí hi tương đối. Do tô màu, cây RB cũng có mức nút cao hơn vì nó có thể chấp nhận các nút màu đỏ giữa các nút đen (có khả năng tăng gấp 2 lần mức) khiến cho việc tìm kiếm (đọc) kém hiệu quả hơn một chút ... nhưng vì nó là một không đổi (2x), nó ở trong O (log n).

Nếu bạn xem xét cú đánh hiệu suất để sửa đổi cây (có ý nghĩa) so với cú đánh hiệu suất của sự tham khảo ý kiến ​​của cây (gần như không đáng kể), thì việc chọn RB hơn AVL trong trường hợp chung là điều tự nhiên.

Nó chỉ là lựa chọn thực hiện của bạn - chúng có thể được thực hiện như bất kỳ cây cân bằng nào. Các lựa chọn khác nhau đều có thể so sánh với sự khác biệt nhỏ. Vì vậy, bất kỳ là tốt như bất kỳ.