Question

How to convert a binary tree to binary search tree in-place, i.e., we cannot use any extra space.

Answer 1

You don’t give much to go on, but if the requirement is what I think it is, you have a binary tree already created and sitting in memory, but not sorted (the way you want it to be sorted, anyway).

I’m assuming that the tree nodes look like

struct tree_node {
    struct tree_node * left;
    struct tree_node * right;
    data_t data;
};

I’m also assuming that you can read C

While we could just sit around wondering why this tree was ever created without having been created in sorted order that doesn’t do us any good, so I’ll ignore it and just deal with sorting it.

The requirement that no extra space be used is odd. Temporarily there will be extra space, if only on the stack. I’m going to assume that it means that calling malloc or something like that and also that the resulting tree has to use no more memory than the original unsorted tree.

The first and easiest solution is to do a preorder traversal of the unsorted tree removing each node from that tree and doing a sorted insertion into a new tree. This is O(n+nlog(n)), which is O(nlog(n)).

If this isn’t what they want and you’re going to have to use rotations and stuff….. that’s horrible!

I thought that you could do this by doing an odd version of a heap sort, but I ran into problems.
Another thing that did come to mind, which would be horribly slow, would to do an odd version of bubble sort on the tree.

For this each node is compared and possibly swapped with each of it’s direct children (and therefore also with its parent) repeatedly until you traverse the tree and don’t find any
needed swaps. Doing a shaker sort (bubble sort that goes left to right and the right to left) version of this would work best, and after the initial pass you would not need to traverse down subtrees that did not look out of order with respect to it’s parent.

I’m sure that either this algorthm was thought up by someone else before me and has a cool name that I just don’t know, or that it is fundamentally flawed in some way that I’m not seeing.

Coming up with the run-time calculations for the second suggestion is a pretty complicated. At first I thought that it would simply be O(n^2), like bubble and shaker sorts, but I can’t satisfy myself that the subtree traversal avoidance might not win enough to make it a little bit better than O(n^2). Essentially bubble and shaker sorts get this optimization too, but only at the ends where total sortedness occurs early and you can chop down the limits. With this tree version you get oppurtunities to possibly avoid chunks in the middle of the set as well. Well, like I said, it’s probably fatally flawed.