7

I've been reading on in place sorting algorithm to sort linked lists. As per Wikipedia

Merge sort is often the best choice for sorting a linked list: in this situation it is relatively easy to implement a merge sort in such a way that it requires only Θ(1) extra space, and the slow random-access performance of a linked list makes some other algorithms (such as quicksort) perform poorly, and others (such as heapsort) completely impossible.

To my knowledge, the merge sort algorithm is not an in place sorting algorithm, and has a worst case space complexity of O(n) auxiliary. Now, with this taken into consideration, I am unable to decide if there exists a suitable algorithm to sort a singly linked list with O(1) auxiliary space.

Alexander
  • 23,432
  • 11
  • 63
  • 73
uyetch
  • 2,150
  • 3
  • 28
  • 33
  • 5
    Your knowledge is incomplete. Merge sort *of arrays* has space complexity of O(n). This is not applicable to linked lists. – n. m. could be an AI Jun 30 '12 at 08:07
  • @n.m. In that case, can you suggest me where I can read about it ? Perhaps a proof or an implementation (pseudo code shall also do) – uyetch Jun 30 '12 at 08:16
  • 2
    [Here](http://www.chiark.greenend.org.uk/~sgtatham/algorithms/listsort.c)'s one implementation which is truly O(1) aux space. – n. m. could be an AI Jun 30 '12 at 08:32
  • Why mergesort is not an in-place sorting algorithm for you? – Alexander Jun 30 '12 at 09:04
  • 1
    That Wikipedia page isn't right: linked lists can be quicksorted without any time penalty. Pick a pivot in O(n) time (or O(1) if you like), then examine each element in turn, adding it to one of two new lists depending on whether it is < or >= the pivot (also O(n)), then recurse on the 2 sublists, then finally join the sorted sublists together with the pivot in between (also O(n), since the most you have to do is walk to the end of the low list to find where the pivot should be inserted). – j_random_hacker Jun 30 '12 at 09:45
  • @ard, so, what was the approach you used? – Alexander Jul 04 '12 at 19:48
  • Link to [wiki pseudo code for bottom up merge sort for linked list](https://en.wikipedia.org/wiki/Merge_sort#Bottom-up_implementation_using_lists) . – rcgldr Mar 19 '21 at 03:42

2 Answers2

5

As pointed out by Fabio A. in a comment, the sorting algorithm implied by the following implementations of merge and split in fact requires O(log n) extra space in the form of stack frames to manage the recursion (or their explicit equivalent). An O(1)-space algorithm is possible using a quite different bottom-up approach.

Here's an O(1)-space merge algorithm that simply builds up a new list by moving the lower item from the top of each list to the end of the new list:

struct node {
    WHATEVER_TYPE val;
    struct node* next;
};

node* merge(node* a, node* b) {
    node* out;
    node** p = &out;    // Address of the next pointer that needs to be changed

    while (a && b) {
        if (a->val < b->val) {
            *p = a;
            a = a->next;
        } else {
            *p = b;
            b = b->next;
        }

        // Next loop iter should write to final "next" pointer
        p = &(*p)->next;
    }

    // At least one of the input lists has run out.
    if (a) {
        *p = a;
    } else {
        *p = b;        // Works even if b is NULL
    }

    return out;
}

It's possible to avoid the pointer-to-pointer p by special-casing the first item to be added to the output list, but I think the way I've done it is clearer.

Here is an O(1)-space split algorithm that simply breaks a list into 2 equal-sized pieces:

node* split(node* in) {
    if (!in) return NULL;    // Have to special-case a zero-length list

    node* half = in;         // Invariant: half != NULL
    while (in) {
        in = in->next;
        if (!in) break;
        half = half->next;
        in = in->next;
    }

    node* rest = half->next;
    half->next = NULL;
    return rest;
}

Notice that half is only moved forward half as many times as in is. Upon this function's return, the list originally passed as in will have been changed so that it contains just the first ceil(n/2) items, and the return value is the list containing the remaining floor(n/2) items.

j_random_hacker
  • 50,331
  • 10
  • 105
  • 169
  • 1
    I might be mistaken, but the fact you use function to split the list in half implies that you're using a top-down approach to the mergesort, which itself requires a stack to be performed, whose size will be O(log(N)). A bottom-up approach can be done iteratively without a stack, and that's how you actually get O(1) size. – Fabio A. Dec 24 '17 at 11:30
  • 1
    @Fabio: You're right. I seem to have tried to weasel out by talking about the merge and split steps using O(1) space, which is true, but as you say, the recursion itself will require O(log n) stack frames of space. I'll edit to mention this. – j_random_hacker Dec 24 '17 at 18:07
  • @FabioA. - link to [wiki bottom up for linked list pseudo code](https://en.wikipedia.org/wiki/Merge_sort#Bottom-up_implementation_using_lists). If sorting a large list of scattered nodes, then most of the node accesses will involve a cache miss, and top down merge sort for linked lists will be about 40% slower than bottom up. – rcgldr Mar 18 '21 at 18:41
1

This somehow kind of remind me about my answer to a Dutch National Flag Problem question.

After giving it some thought this is what I came up to, let's see if this works out. I suppose the main problem is the merging step of the mergesort in O(1) extra-space.

Our representation of a linked-list:

[ 1 ] => [ 3 ] => [ 2 ] => [ 4 ]
  ^head                      ^tail

You end up with this merging step:

[ 1 ] => [ 3 ] => [ 2 ] => [ 4 ]
  ^p                ^q       ^tail

Being p and q the pointers for the segments we want to merge.

Simply add your nodes after the tail pointer. If *p <= *q you add p at the tail.

[ 1 ] => [ 3 ] => [ 2 ] => [ 4 ] => [ 1 ]
  ^p       ^pp      ^q/qq    ^tail    ^tt

Otherwise, add q.

[ 1 ] => [ 3 ] => [ 2 ] => [ 4 ] => [ 1 ] => [ 2 ]
  ^p       ^pp      ^q       ^qq/tail          ^tt

(Keeping track of the ending of our list q becomes tricky)

Now, if you move them you will rapidly lose track of where you are. You can beat this having a clever way to move your pointers or add the lengths into the equation. I definitely prefer the latter. The approach becomes:

[ 1 ] => [ 3 ] => [ 2 ] => [ 4 ]
  ^p(2)             ^q(2)    ^tail

[ 3 ] => [ 2 ] => [ 4 ] => [ 1 ]
  ^p(1)    ^q(2)             ^tail

[ 3 ] => [ 4 ] => [ 1 ] => [ 2 ]
  ^p(1)    ^q(1)             ^tail

[ 4 ] => [ 1 ] => [ 2 ] => [ 3 ]
  ^p(0)/q(1)                 ^tail

[ 1 ] => [ 2 ] => [ 3 ] => [ 4 ]
  ^q(0)                      ^tail

Now, you use that O(1) extra-space to be able to move your elements.

Community
  • 1
  • 1
Alexander
  • 23,432
  • 11
  • 63
  • 73