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*(*n*^{2})-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.0~~11.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 ).

Auto comment: topic has been updated by kobae964 (previous revision, new revision, compare).Auto comment: topic has been updated by kobae964 (previous revision, new revision, compare).Auto comment: topic has been updated by kobae964 (previous revision, new revision, compare).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.05s

Random order : http://ideone.com/BeNbvZ 0.12s

I suspect that

`Box::new`

s always consume heap memory like dealing with persistent data structures.Ah, I didn't notice that fn depth takes O(n)-time...

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.Auto comment: topic has been updated by kobae964 (previous revision, new revision, compare).