平衡二叉尋找樹

二叉尋找樹是一種非常有用的資料結構。經過一定擴充，它可以支援的操作有：Insert（插入）、Find（尋找）、Remove（刪除）、GetMax（取最大）、GetMin（取最小）、Prev（取前驅）、Next（取後繼）、Rank（取某元素的序號）、Select（按照序號取該元素）。如果資料是隨機的話，以上操作可以保證在O(logn)的期望時間內完成。但是比賽中顯然出題者會給出一些刁鑽的資料讓最普通的二叉尋找樹嚴重TLE，這便是平衡二叉樹得以應用的時候了。平衡二叉樹可以保證以上操作是嚴格（AVL）或均攤（Splay）或期望（Treap）的O(logn)的時間複雜度。

平衡二叉樹的實現一般有三種情形：遞迴、Top-Down（自頂向下）、Buttom-Up（自底向上）。遞迴實現可能比較好寫，比如Treap的遞迴實現就非常短，基本的插入刪除二三十行就可以搞定。Splay的一種實現方法也是遞迴，但這種方法是不推薦使用的。因為Splay雖然保證均攤的時間複雜度，但並不保證高度（AVL保證高度是嚴格的O(logn)、Treap保證高度是期望O(logn)），這就造成面對某些刁鑽的資料時雖時間上不會出問題，卻可能由於遞迴層次過多造成棧溢出。（例如連續大量升序的插入會使Splay變成一條長鏈，此時訪問最底端的節點就會造成棧溢出。）所以Splay比較好的編寫方法還是Top-Down或者Buttom-Up，它們都是非遞迴的。其中Top-Down的核心Splay過程有大約三四十行，效能十分優異，雖然不太好理解但是強記住也是可取的。Buttom-Up的Splay我沒寫過，但我知道一切Buttom-Up的平衡樹都需要維護每個節點的父指標，造成了一定的編程複雜度也容易出錯（比如說最基本的旋轉操作就比以前麻煩多了）。Treap也可以寫成Buttom-Up，不過我覺得沒必要——既然選擇了Treap當然就是為了它的編程複雜度低，寫Buttom-Up的Treap還不如寫成Top-Down或Buttom-Up的Splay，沒準行數還更少呢。但相對於遞迴實現以及Buttom-Up來說，Top-Down的缺點是很難維護每個節點的Size域（即這棵子樹的節點數或者其左子樹的節點數），事實上我一直認為Top-Down Splay是無法在均攤O(logn)的和不記錄父指標的前提下加入維護size域的操作的——這兩個前提若不滿足則或失去了Splay的本質，或失去了Top-Down的精髓。綜上所述呢，在考試時選擇寫哪種平衡樹應該這樣考慮：不需要Size且資料量極大時用Top-Down Splay，需要Size或資料量一般時用遞迴Treap，這兩者我都有把握在15min內寫對；Buttom-Up的唯一好處是既非遞迴又能維護Size，但似乎書寫是最麻煩的，何況我沒寫過，所以就不考慮了。

下面說說平衡樹的操作。Insert和Remove這種需要改變樹中元素的操作因平衡方式而異，就不細說了。Find的基本方法就是不斷比較待尋找值與當前節點，若小於則向左，大於則向右，等於就找到了；Splay的Find有所不同，只要Splay這個值一下看看根部有沒有就行了。 GetMax是從根一直向右走直至無法再走就找到了最大值，GetMin反之，注意Splay中還需要把找到的最值再Splay一下，否則無法保證均攤的複雜度。Prev是對當前值向左走一步然後一直向右，Next相反；對於Splay只要把它先伸展到根部再這樣找就行了，但對於Treap，若它的左子樹或右子樹是空的，注意需要返回的反而是某個祖先節點，用遞迴實現或Buttom-Up比較簡便。Rank操作只須記錄每個節點的子樹的大小，然後比較當前值與左子樹的大小把它分到左邊或者右邊，如果分到右邊要把左子樹和當前節點的大小都加到答案裡，一般就都採用非遞迴的實現了（反正是一個容易消除的尾遞迴）。Select基本與Rank類似，也是不斷比較這個序號與左子樹的大小，就能知道答案在左邊還是右邊了。

以上操作中GetMin、GetMax可以以每次操作相同的時間複雜度上界代替二元堆積，比單純的二元堆積的優點是支援了方便的尋找和刪除，還可以同時找最大值和最小值。Prev、Next、Rank、Select等操作在很多題中也各有應用。

總的來說，對於這種用處廣泛考察很多的資料結構來說，最好還是透徹地理解、熟練的背誦。

April 19, 2007 · Filed under 程式園