Question

I don’t quite understand why the rotation in the splay tree data structure is taking into account not only the parent of the rating node, but also the grandparent (zig-zag and zig-zig operation). Why would the following not work:

as we insert, for instance, a new node to the tree, we check whether we insert into the left or right subtree. If we insert into the left, we rotate the result RIGHT, and vice versa for right subtree. Recursively it would be sth like this

Tree insert(Tree root, Key k){
    if(k < root.key){
        root.setLeft(insert(root.getLeft(), key);
        return rotateRight(root);
    }
    //vice versa for right subtree
}

That should avoid the whole “splay” procedure, don’t you think?

Answer 1

The algorithm you’re proposing on the tree is called the “move-to-root” heuristic and is discussed on page four of Sleator and Tarjan’s original paper on splay trees. They cite an older paper by Allen and Munro where it is shown that if you try to use move-to-root as a means for reshaping trees, it is possible for the amortized cost of each lookup to be O(n), which is quite slow. Splaying is a very carefully designed algorithm for reshaping the tree, and it guarantees amortized O(log n) lookups no matter what sequence of accesses is performed.

Intuitively, move-to-root is not a very good way to reshape the tree because it moves down all the nodes on the path from the node to the root while trying to make the accessed node easier to reach in the future. As a result, the overall tree can get worse when doing this version of tree reorganizing. On the other hand, the splay method tends to decrease the height of the splayed node and all of the nodes on its access path, which means that as a whole the tree tends to get better during a splay.

Hope this helps!