「笔记」递归算法复杂度分析

写在前面

可恶的算法分析与设计!!!

递归算法形式

对于一个输入规模为 n 的递归算法,每次均为将整个问题划分为 a 个规模为 nb 的子问题,回溯时将所有子问题合并需要 f(n) 的时间,定义函数 T(n) 代表该递归算法所需时间,则有递推式:

n>b, T(n)=aT(nb)+f(n)

递归树大力求和

根据递推式画出递归树。对于上述递归式其递归树形如:

  1. 根节点代表规模为 n 的原问题。
  2. 对于规模为 x 的节点,其子节点数为 a,代表该问题分治后的所有规模为 xb 的子问题。
  3. 对于规模为 x 的问题对应的子节点,节点上的值为 f(x)
  4. 每层的右侧标出当前层中所有节点的和。

对递归树逐层右侧的值求和求和即得 T(n) 的值。

一个实例:

图片来源:https://blog.csdn.net/ypxcan/article/details/120452530

主定理 Master Theorem

对于上述函数 T(n),有:

n>b, T(n)=aT(nb)+f(n)

T(n)={Θ(nlogba)ϵ>0,f(n)=O(nlogb(a)ϵ)(1)Θ(f(n))ϵ0,f(n)=Ω(nlogb(a)+ϵ)(2)Θ(nlogbalogk+1n)k0,f(n)=Θ(nlogbalogkn)(3)

特别地,情况(2)中还需满足存在常数 c<1,当 n+af(nb)cf(n) 恒成立。

证明即考虑将上述时间含义的递归树并逐层求和,上述公式中莫名奇妙的 nlogba 实际上即为递归树最底层的所需时间为 Θ(1) 的子问题数量。具体证明过程详见 OI-wiki

根据证明过程可以得到上述三种情况分别代表的实际情况:

  • (1)瓶颈在于处理所有叶节点所需时间 Θ(1)×O(nlogba)
  • (2)瓶颈在于分割与合并过程 f(n)
  • (3)分割与合并过程与处理所有叶节点所需时间同级,上述额外限制 af(nb)cf(n) 即限制了原问题分割后子问题的增长速率不会超过其本身。

典题

大部分情况下可以直接套主定理秒了,如果套不上公式只能大力求和。

1

T(n)={1(n=1)2T(n2)+1(n>1)

a=2,b=2,logba=log22=1。当取 ϵ(0,1] 时,有 f(n)=O(nlogb(a)ϵ)=O(n1ϵ),则由主定理(1)有:

T(n)=Θ(nlogba)=Θ(n)

2

T(n)={1(n=1)T(n2)+n(n>1)

a=1,b=2,logba=log21=0。当取 ϵ(0,1] 时,有 f(n)=Ω(nlogb(a)+ϵ)=O(nϵ),则由主定理(2)有:

T(n)=Θ(f(n))=Θ(n)

3

T(n)={1(n=1)2T(n2)+n(n>1)

即为归并排序的复杂度。递归树见上述图片实例。

a=2,b=2,logba=log22=1。当取 k=0 时,有 f(n)=Θ(nlogbalogkn)=Θ(n),则由主定理(3)有:

T(n)=Θ(nlogbalogk+1n)=Θ(nlogn)

4

T(n)={1(n=1)2T(n2)+nlogn(n>1)

CDQ 分治的复杂度。

a=2,b=2,logba=log22=1。当取 k=1 时,有 f(n)=Θ(nlogbalogkn)=Θ(nlogn),则由主定理(3)有:

T(n)=Θ(nlogbalogk+1n)=Θ(nlog2n)

写在最后

奇怪的是网络上搜到的主定理的定义都是不完全的,比如以下参考中指出的那篇,在他们的定义下会出现明明可以适用主定理但是不存在于定义中的情况。为什么会有这种残疾版的定义?莫名奇妙!

要不是我现在妈的忙着傻逼期末我一定去溯源妈的傻逼期末

反转了,真正的主定理其实是:

=6

参考:

posted @   Luckyblock  阅读(66)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· SQL Server 2025 AI相关能力初探
· AI编程工具终极对决:字节Trae VS Cursor,谁才是开发者新宠?
· 开源Multi-agent AI智能体框架aevatar.ai,欢迎大家贡献代码
· Manus重磅发布:全球首款通用AI代理技术深度解析与实战指南
点击右上角即可分享
微信分享提示