### kobae964's blog

By kobae964, history, 8 months ago, ,

UPD: Fixed the code (insertion in a random order), based on the comment.

I recently implemented Treap, one of various kinds of binary search trees (BSTs), on Rust. It is a balanced BST, which means that it ensures that tree depth is always where n =  (the number of items in a tree). That is achieved by using randomisation. (For more details see Treap — Wikipedia.)

## Experiments

Here are results of some experiments (UPD: these experiments themselves take O(n2)-time, because function depth() takes O(n)-time, which is called in each iteration.):

(1) Insertion of 10000 elements in the ascending order:
http://ideone.com/tSrw7u
It took 11.7 seconds to insert 30000 elements in the ascending order, and it got Time Limit Exceeded (>15.0sec) when the number of elements is >100000. You'll see that the depth of the treap increases in logarithmic speed.

(2) Insertion of 10000 elements in a random order:
http://ideone.com/pW7sBf
It took 15.011.8 seconds to insert 30000 elements in a random order. Like (1), the depth of the treap increases in logarithmic speed, too.

Here is a graph that indicates how the depth of the treap grows as the number of elements increases. The horizontal line shows the number of nodes in the treap and the vertical one shows the depth of the treap.

## Conclusion

We have a balanced BST, whose depth is bounded by !
Unfortunately, a solution (25637342) to 785E - Anton and Permutation that uses this treap, which should work in -time, got the Time limit exceeded verdict. That seems because of its heavy constant factor, but I'm not sure.

## References

The code I used in these experiments is avaliable at: https://github.com/koba-e964/contest/blob/906fcb07057b72496407b3c6e6a422e48e60dc6f/comm/Treap.rs
http://ideone.com/tSrw7u
http://ideone.com/pW7sBf

This implementation of treap largely depends on the slide (https://www.slideshare.net/iwiwi/2-12188757, written in Japanese) by iwiwi. This implementation of treap is verified by http://arc061.contest.atcoder.jp/submissions/1172709 (AtCoder ARC 061 D, problem statement is avaliable at http://arc061.contest.atcoder.jp/tasks/arc061_b ).

•
• +14
•

 » 7 months ago, # |   +8 Auto comment: topic has been updated by kobae964 (previous revision, new revision, compare).
 » 7 months ago, # |   +8 Auto comment: topic has been updated by kobae964 (previous revision, new revision, compare).
 » 7 months ago, # |   +8 Auto comment: topic has been updated by kobae964 (previous revision, new revision, compare).
 » 7 months ago, # | ← Rev. 2 →   +10 There seems to be an error on line 215 of your random order version. To correct, it will be `bst = bst.insert(elem, next());`, I think.BTW, my implementation runs faster than yours!Ascending order : http://ideone.com/NZ8ra2 0.05sRandom order : http://ideone.com/BeNbvZ 0.12sI suspect that `Box::new`s always consume heap memory like dealing with persistent data structures.
•  » » 7 months ago, # ^ |   0 Ah, I didn't notice that fn depth takes O(n)-time...
•  » » » 7 months ago, # ^ |   0 Thank you for your comment. I fixed the code (one using a random order) based on it.The fact that depth() takes O(n)-time has slipped off from my mind, too. It is now mentioned in the post.
 » 7 months ago, # |   +8 Auto comment: topic has been updated by kobae964 (previous revision, new revision, compare).