kobae964's blog

By kobae964, history, 2 months ago, In English,

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 ).

 
 
 
 
  • Vote: I like it  
  • +14
  • Vote: I do not like it  

»
5 weeks ago, # |
  Vote: I like it +8 Vote: I do not like it

Auto comment: topic has been updated by kobae964 (previous revision, new revision, compare).

»
5 weeks ago, # |
  Vote: I like it +8 Vote: I do not like it

Auto comment: topic has been updated by kobae964 (previous revision, new revision, compare).

»
5 weeks ago, # |
  Vote: I like it +8 Vote: I do not like it

Auto comment: topic has been updated by kobae964 (previous revision, new revision, compare).

»
5 weeks ago, # |
Rev. 2   Vote: I like it +10 Vote: I do not like it

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::news always consume heap memory like dealing with persistent data structures.

  • »
    »
    5 weeks ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    Ah, I didn't notice that fn depth takes O(n)-time...

    • »
      »
      »
      5 weeks ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      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.

»
5 weeks ago, # |
  Vote: I like it +8 Vote: I do not like it

Auto comment: topic has been updated by kobae964 (previous revision, new revision, compare).