• 关于递归调用的深度


    题目源自牛客网:

    1.对n个记录的线性表进行快速排序为减少算法的递归深度,以下叙述正确的是()

    正确答案: A   你的答案: A (正确)

    每次分区后,先处理较短的部分
    每次分区后,先处理较长的部分
    与算法每次分区后的处理顺序无关
    以上三者都不对

    来看一个别人的答案:“考虑一种极端情况,如果每次确定pivot后短的部分都为1,先处理短的部分,短的部分处理完后就会出栈,那么辅助栈的深度为O(1)即可,同理,如果先处理长的部分,较长的部分不断递归压栈, 辅助栈的深度就是O(n)。所以,如果每次都先处理较短的部分,那么长而化小,栈区的深度较小,反之,较长的部分不断递归压栈,栈区的长度就会大。”

    可能这样讲还比较抽象,那来看最高票的一个举例子的解释:
    “看到很多人在别的答案下说看不懂,那我就来举个栗子。
    现在有这么个序列:123456789
    假设每次划分出短序列的长度为1
    即第一次划分
    短序列:1
    长序列:23456789
    如果优先处理短序列1
    则栈中仅用保存23456789,深度为1
    然后23456789出栈,划分
    短序列:2
    长序列:3456789
    同样的先处理短序列
    栈中保存3456789,深度为1
    类推下去,处理完整个序列,栈的最大深度都为1

    假如每次划分出的短序列长度为2呢
    短序列:12
    长序列:3456789
    优先处理短序列12
    栈中保存3456789 深度为1
    12只能划分为同样长度的序列1和2
    先处理左边的
    栈保存2 此时栈中有3456789 和 2 深度为2
    然后2 出栈 处理
    接着3456789出栈
    划分为短序列34
    长序列 56789
    处理短序列34
    栈中保存56789
    类推下去,处理完整个序列,栈的最大深度都为2

    也就是说栈的最大深度取决于划分出来的短序列的长度 (前提是先处理短序列)

    那么先处理长序列呢
    短序列:1
    长序列:23456789
    如果优先处理长序列序列23456789 短序列入栈,长序列划分为2和3456789
    2入栈,3456789划分
    。。。
    8入栈,9处理
    此时栈中有12345678 深度为8

    短序列:12
    长序列:3456789
    12入栈 3456789划分为34和56789
    34入栈 56789划分为56和789
    56入栈 789划分为78和9
    9入栈  78划分为7和8
    7入栈 8处理
    此时栈中有12 34 56 9 7 深度为5

    很明显先处理长序列 栈的深度要大于 先处理短序列栈的深度。”

    如果还没看懂那可以自己在纸上写一个例子出来。


    2.采用递归方式对顺序表进行快速排序,下列关于递归次数的叙述中,正确的是()

    正确答案: D   你的答案: C (错误)

    递归次数与初始数据的排列次序无关
    每次划分后,先处理较长的分区可以减少递归次数
    每次划分后,先处理较短的分区可以减少递归次数
    递归次数与每次划分后得到的分区处理顺序无关


    A选项:快速排序中,如果序列初始化就有序:123456,那么明显只需要递归一次就好了,因为右边先启动的哨兵一直走呀走走到数字1的位置才停下来,那下面就已经无需再递归了,直接得出结果了(这里需要事先理解快速排序的流程,可参考我的另一篇博客:快速排序C++)。所以显然至少在快排当中,递归的次数是跟初始数据的排列次序是有关的。

    后面三个选项:每次划分应该先处理较短的分区,只是减少递归占用的内存空间(每次调用栈的深度),并不能减少次数,该比较那么多次还是得比较那么多次。每次划分先处理较短的分区,那其实相当于:切瓜子,固定要均分切成一样厚度的薄片,然后我每次拿较短的一段先切掉,然后再回到长的一段继续分切,其实最终要切的次数还是那么多的,只是会给人一种心理安慰似的,因为每次不用切太久(递归深度较浅)我就切完了一段,很有成就感是吧。。。然而最终要切的次数还是一样多的。

  • 相关阅读:
    IT资产管理系统SQL版
    反转单词(C#实现)
    删除数组中重复的元素(C#实现)
    最大子数组之和(C#实现)
    判断是否是三角形
    如何解决SSAS + SSRS + WSS3.0 之间的Windows 集成验证问题
    关于SharpDevelop
    规划一个SharePoint的解决方案
    Scalability Design
    合作意味着分享
  • 原文地址:https://www.cnblogs.com/lvlang/p/10586366.html
Copyright © 2020-2023  润新知