Cấu trúc từ điển sắp xếp hỗ trợ hợp nhất hiệu quả?

Nhiều cấu trúc cây cân bằng (cây đỏ / đen, cây splay, v.v.) và một số cấu trúc từ điển được sắp xếp khác (skiplists) hỗ trợ thao tác nối có hai từ điển trong đó tất cả các khóa trong cấu trúc đầu tiên đều nhỏ hơn tất cả các khóa trong giây, sau đó kết hợp hai từ điển thành một từ điển được sắp xếp duy nhất trong thời gian , trong đó là tổng số khóa. Tuy nhiên, điều này chỉ hoạt động nếu không có sự trùng lặp trong phạm vi các khóa được lưu trữ trong các cây đó.$O(\log n)$$n$

Tương tự, nhiều hàng đợi ưu tiên (heap nhị phân, heap Fibros, v.v.) hỗ trợ hợp nhất thời gian . Các kết hợp này hoạt động bất kể khóa nào được lưu trữ, nhưng do cấu trúc dữ liệu là hàng đợi ưu tiên, chúng ta không thể tìm kiếm các phần tử ngẫu nhiên trong cấu trúc kết quả.$O(\log n)$

Có cấu trúc từ điển được sắp xếp nào hỗ trợ hợp nhất các từ điển tùy ý trong thời gian đồng thời hỗ trợ các hoạt động từ điển được sắp xếp bình thường (chèn, xóa, tra cứu, truy vấn kế nhiệm / tiền nhiệm, v.v.) trong thời gian hoặc bằng chứng ràng buộc thấp hơn rằng các cấu trúc như vậy không thể tồn tại?$O(\log n)$$O(\log n)$

Nếu bạn có cấu trúc dữ liệu cây tìm kiếm nhị phân cân bằng với thuộc tính cây tìm kiếm ngón tay (việc tìm kiếm một mục vị trí sẽ mất thời gian ), chẳng hạn như cây splay, thì nếu bạn chèn một chuỗi đã sắp xếp trong số mục vào đó, tổng thời gian để chèn sẽ là .$d$$O(\log d)$$k$$O(k\log(n/k))$

Bây giờ, giả sử rằng bạn muốn hỗ trợ chèn, hợp nhất phá hủy và tìm kiếm. Đối với các phần chèn và tìm kiếm, chỉ cần sử dụng các hoạt động của cây tìm kiếm hiện có. Để hợp nhất, luôn luôn hợp nhất cây nhỏ hơn thành cây lớn hơn và sử dụng một giao dịch theo thứ tự của cây nhỏ hơn để có được thứ tự sắp xếp của nó trong thời gian tuyến tính. Sau đó, chèn từng phần tử của cây nhỏ hơn vào cây lớn hơn theo thứ tự được sắp xếp này.

Nếu một phần tử được chèn sau đó được hợp nhất thành một chuỗi các cây lớn hơn với kích thước thì lượng thời gian để chèn và hợp nhất (chỉ tính một phần của tổng thời gian hợp nhất) sẽ là , , , thêm vào một chuỗi kính thiên văn vào . Vì vậy, nếu người ta sử dụng sơ đồ khấu hao trong đó tổng thời gian logarit này cho một chuỗi hợp nhất tiềm năng được tính cho hoạt động chèn cho , thì chúng ta vẫn nhận được thời gian khấu hao cho mỗi lần chèn hoặc tìm kiếm và chỉ khấu hao thời gian trên mỗi hợp nhất.$x$$n_1, n_2,\dots$O ( log n 1 ) O ( log ( n 2 / n 1 ) ) ... O ( log n ) x O ( log n ) O ( 1 $x$$O(\log n_1)$$O(\log(n_2/n_1))$$\dots$$O(\log n)$$x$$O(\log n)$$O(1)$

Xóa làm phức tạp phân tích này, nhưng không nhiều. Một cách để xử lý chúng là xóa một nửa lười biếng, trong đó một mục bị xóa được xóa khỏi cây của nó nhưng không bị xóa khỏi số lượng vật phẩm trong cây này, để khi chúng ta quyết định hai cây nào nhỏ hơn hoặc lớn hơn chúng ta đếm tất cả các vật phẩm đã từng có trên cây. Sau đó, trongO ( log n $n$$O(\log n)$thời gian cho mỗi thao tác phải là tổng số mục đã từng được chèn hoặc xóa thay vì số hiện tại. Nếu hai số này phát triển quá xa nhau, bạn có thể tạo một bản cập nhật điều chỉnh lại tất cả số đếm thành số thực của chúng, đặt lại cấu trúc dữ liệu về trạng thái không có mục bị xóa; thời gian khấu hao cho bản cập nhật này có thể được tính vào các thao tác xóa mà bạn phải thực hiện để có được các số cách xa nhau. Hoặc có thể bạn có thể làm cho việc khấu hao hợp nhất hoạt động trực tiếp với việc xóa không lười biếng, nhưng tôi chưa tìm ra chi tiết của phần đó.