深入浅出数据结构C语言版（19）——堆排序

标签：orm   com   alt   html   span   表示   缺陷   顺序   sign   

　　在介绍优先队列的博文中，我们提到了数据结构二叉堆，并且说明了二叉堆的一个特殊用途——排序，同时给出了其时间复杂度O(N*logN)。这个时间界是目前我们看到最好的（使用Sedgewick序列的希尔排序时间复杂度为O(N^4/3)，下图为两者函数图像对比，但是注意，这并不是希尔排序与堆排序的对比，只是两个大O阶函数的对比）。这篇博文，我们就是要细化用二叉堆进行排序的想法，实现堆排序。

　　在介绍优先队列的博文中（http://www.cnblogs.com/mm93/p/7481782.html）所提到的用二叉堆排序的想法可以简单地用如下代码表示：

void HeapSort(int *src,int size)
{
        //BuildHeap即根据所给数组建立一个二叉堆并返回
    struct BinaryHeap *h = BuildHeap(a, size);

        //有了二叉堆后，只需不断DeleteMax得到根结点，然后输出到目标数组即可
        //此循环结束后，src数组中就有了从小到大的顺序
    for (int i = size-1;i >=0 ;--i)
    {
        src[i] = DeleteMax(h);
    }
}

　　虽然介绍优先队列的博文中没有BuildHeap和DeleteRoot函数，但学会了二叉堆的话，这两个函数不难写出，BuildHeap其实就是Initialize函数与Insert函数的结合，而DeleteMax也和Dequeue思路相同，即删除并返回堆的根，前提是建立的堆满足任一结点均大于其孩子，即Max型堆，与介绍二叉堆时实现的Min型堆恰好相反。

　　至此，堆排序的实现就算是完成了，但是不难发现上述实现方法有一个缺陷，就是原数组src占用了空间N，建立的堆h又占用了空间N，也就是说该实现耗费的空间是插入排序、希尔排序的两倍。那么是否存在解决这个空间问题的办法呢？答案是有，解决的办法就是：直接将原数组src改成一个二叉堆，而后每次DeleteMax，将所得原堆根放置在原堆尾，size次DeleteMax后src就会变为从小到大的顺序（执行DeleteMax后，原堆尾对于堆来说就是“废弃”的，可以用于存储“删掉的根”。希望最后顺序为有小到大是我们将DeleteMin改为DeleteMax的原因，如果需要从大到小的顺序，则应为DeleteMin）

　　上述解决办法中最难的一环可能就是“将src改为一个二叉堆”。BuildHeap的实现简单，只需要建立一个足够大的空堆，而后不断将数据Insert即可，而Insert的思路就是“将新元素从堆尾开始进行上滤”。那么Insert的这个思路是否可以用于将数组直接改造为二叉堆呢？比如先让src[size-1]上滤，然后src[size-2]上滤……答案是不行！因为Insert的上滤前提是向“已存在的堆”插入数据，“已存在的堆”要么为空，要么处处符合堆的要求。而src数组是“一片乱”的，这个想法是不行的。

　　阐述正确做法之前，我们先要明确一个不容易注意到的点：在优先队列中，堆可以舍弃掉数组[0]的位置，这样可以使编程更加方便，即任一数组[i]的孩子就是数组[i*2]和数组[i*2+1]，而数组[i]的父亲则是数组[i/2]。但是如果是将src直接改造为二叉堆，则不能舍弃src[0]，因为我们认为src应是满的数组。因此，将src改造为二叉堆后，任一src[i]的孩子应为src[i*2+1]与src[i*2+2]，而src[i]的父亲则应为src[(i-1)/2]

　　接下来我们说说将src直接改造为二叉堆的方法：令i=(size-1)/2，即src[i]为src[size-1]的父亲，然后令src[i]下滤，src[i]下滤结束后，令i--，重复此过程直至i=-1。

　　上述方法之所以可行，是因为按i初始值为(size-1)/2，而后i--的顺序执行下滤的话，每个以src[i]为根的堆都只有src[i]是不符合堆要求的，此时只需要让src[i]下滤即可，根本思路与DeleteRoot的下滤是一样的。

　　这个方法实现起来非常简单：

//cur即当前进行下滤的元素的下标，FilterDown即下滤之意
void FilterDown(int *src, int cur, unsigned int size)
{
    //先暂存下滤元素的值，避免实际交换
    int temp = src[cur];
    unsigned int child;

    //child初始值为src[cur]左孩子下标
    for (child = cur * 2 + 1;child < size;child = child * 2 + 1)
    {
        //若src[cur]存在右孩子，且右孩子比左孩子大，则令child为右孩子下标，即令child为src[cur]更大的孩子的下标
        if (child < size - 1 && src[child] < src[child + 1])
            child++;
        //比较下滤元素与src[child]，若小于，则令src[child]上移，否则下滤结束
        if (temp < src[child])
            src[(child - 1) / 2] = src[child];
        else
            break;
    }
    //下滤结束后的child对应的父亲即下滤元素应处的位置
    src[(child - 1) / 2] = temp;
}

void TransformToHeap(int *src, unsigned int size)
{
    for (int i = (size - 1) / 2;i >= 0;--i)
        FilterDown(src, i, size);
}

　　解决了最难的改造二叉堆后，堆排序的剩余操作也就不难实现了：

void HeapSort(int *src, unsigned int size)
{
    TransformToHeap(src, size);

    //不断地将堆的根与堆的尾（最后一个叶子）交换，交换后新的堆根为原堆尾，令新堆根下滤。
    //此操作与堆的DeleteRoot本质相同，只是将所得原堆根放在了原堆尾处，从而利用了废弃空间
    for (int oldTail = size - 1;oldTail > 0;--oldTail)
    {
        int temp = src[0];
        src[0] = src[oldTail];
        src[oldTail] = temp;
        FilterDown(src, 0, oldTail - 1);
    }
}

　　至此，堆排序算是改善好了。接下来要讨论的问题就是，为什么堆排序时间复杂度那么好，却不如快速排序？（快速排序最坏情况为O(N²)，平均为θ(N*logN)）

　　这个问题很难解答，因为随着DeleteMax操作，堆的内部结构一直是不稳定的。但我们可以分成三个方面来试着解释一下。

　　第一，我们要明白大O阶只是一个简写的时间界，即使是1000000000*N*logN+100000000000，我们依然是写作O(N*logN)，因此两个同为O(N*logN)的算法并不意味着两者时间上会很接近。套用到堆排序与快速排序中，就是堆排序虽然也是O(N*logN)，但是其常数项比快速排序的平均界θ(N*logN)要大得多，大多少，我不知道╮(╯_╰)╭。

　　第二，从计算机的底层来说，CPU与内存之间存在缓存，缓存一般存储着最近访问的数据所在的数据块，假设来说，因为我们访问了内存中的src[100]，所以CPU将src[80]到src[120]都放入了缓存，这之后如果我们访问src[80]到src[120]之间的数据就会很快，因为它们在缓存之中。但是，堆排序中相邻操作所访问的数据“距离太远了”，比如我们访问了src[100]后要访问其孩子进行比较，则我们需要访问src[201]或src[202]，而它们很可能不在缓存中，因此对它们的访问会比访问缓存中的数据更慢，并且我们访问其孩子后，并不一定会与父结点进行交换，如果是这样，那此次访问就可以说是“花了大代价确定了这件事不需要做”。而在快速排序中相邻的两次访问一般是相邻的，进行远距离访问时都是需要进行交换操作的时候，也就是说快速排序可以比堆排序更好的利用CPU缓存

　　第三，在堆排序中，DeleteMax函数的无效比较与无效交换比例很高，怎么说呢？因为我们在拿走原堆根后，是拿原堆尾到根处，然后进行下滤的，但是直观的说，原堆尾作为“堆中较小元素”，其比原堆根的孩子要大的概率是很低的，也就是说原堆尾拿到根处几乎不用比就知道要下滤，然而我们还是得进行比较、交换。从这个角度来说，将原堆尾拿到根处下滤是做了很多无效工作的，但这又是不得不为之的，因为我们必须得保持堆的完全二叉树性质。也就是说，为了保持堆的特性，我们做了不少额外的操作。

　　关于第三点，我们可以看看介绍优先队列的博文中关于堆删除操作的例子，不难看出，将原堆尾元素31从根处进行下滤，最后其还是下滤到了原有深度：

　　最后，对大小为10000，元素随机的数组进行模拟测试显示，快速排序执行的交换操作次数比堆排序要少很多很多：

　　不过，虽然我们将堆排序“狠狠地”批判了一番，其时间界依然是不错的，毕竟最坏情况也就是O(N*logN)，当然，这个最坏情况恐怕也是个平均情况（注意，这一点并没有被证明），因为在实际使用中，面对大量数据时堆排序往往是远不如快速排序的。此外，据称堆排序的实际效果甚至不如使用Sedgewick序列的希尔排序。基于上述种种原因，一般来说，我们还是按照介绍希尔排序的博文中所说的：将插入排序作为“初级排序”，希尔排序作为“中级排序”，快速排序作为“高级排序”。

　　那么，作为“高级排序”的快速排序究竟是怎样的呢？我们下一篇博文将会介绍。

深入浅出数据结构C语言版（19）——堆排序

标签：orm   com   alt   html   span   表示   缺陷   顺序   sign   

原文地址：http://www.cnblogs.com/mm93/p/7562807.html