算法效率的度量方法
上一讲中我们提到设计算法要尽量的提高效率，这里效率高一般指的是算法的执行时间。
那么我们如何来度量一个算法的执行时间呢？
所谓“是骡子是马拉出来遛遛”，比较容易想到的方法就是我们把算法跑若干次，然后拿个“计时器”在旁边计时。
这种事后统计方法看上去的确不错，并且也并非真的要你拿个计算器在那里计算，因为计算机都有计时功能。
事后统计方法：这种方法主要是通过设计好的测试程序和数据，利用计算机计时器对不同算法编制的程序的运行时间进行比较，从而确定算法效率的高低。
但这种方法显然是有很大缺陷的：
- 必须依据算法事先编制好测试程序，通常需要花费大量时间和精力，完了发觉测试的是糟糕的算法，那不是功亏一篑？赔了娘子又折兵？
- 不同测试环境差别不是一般的大！
我们把刚刚的估算方法称为事后诸葛亮。我们的计算机前辈们也不一定知道诸葛亮是谁，为了对算法的评判更为科学和便捷，他们研究出事前分析估算的方法。
事前分析估算方法：在计算机程序编写前，依据统计方法对算法进行估算。
经过总结，我们发现一个高级语言编写的程序在计算机上运行时所消耗的时间取决于下列因素：
1. 算法采用的策略，方案
2. 编译产生的代码质量
3. 问题的输入规模
4. 机器执行指令的速度
由此可见，抛开这些与计算机硬件、软件有关的因素，一个程序的运行时间依赖于算法的好坏和问题的输入规模。（所谓的问题输入规模是指输入量的多少）
我们搬回高斯先生的那个算法来跟大家谈谈：
第一种算法：
int i, sum = 0, n = 100; // 执行1次
for( i=1; i <= n; i++ ) // 执行了n+1次
{
sum = sum + i; // 执行n次
}
第二种算法：
int sum = 0, n = 100; // 执行1次
sum = (1+n)*n/2; // 执行1次
第一种算法执行了1+(n+1)+n=2n+2次。
第二种算法，是1+1=2次
如果我们把循环看做一个整体，忽略头尾判断的开销，那么这两个算法其实就是n和1的差距。
有些喜欢跟真理死磕的朋友可能对这观点意见不是一般的大！
因为循环判断在算法1里边执行了n+1次，看起来是个不小的数量，凭什么说忽略就能忽略？
淡定，请接着继续看延伸的例子：
int i, j, x=0, sum=0, n=100;
for( i=1; i <= n; i++ )
{
for( j=1; j <= n; j++ )
{
x++;
sum = sum + x;
}
}
这个例子中，循环条件i从1到100，每次都要让j循环100次，如果非常较真的研究总共精确执行次数，那是非常累的。
另一方面，我们研究算法的复杂度，侧重的是研究算法随着输入规模扩大增长量的一个抽象，而不是精确地定位需要执行多少次，因为如果这样的话，我们就又得考虑回编译器优化等问题，然后，然后就永远也没有然后了！
所以，对于刚才例子的算法，我们可以果断判定需要执行100^2次。
我们不关心编写程序所用的语言是什么，也不关心这些程序将跑在什么样的计算机上，我们只关心它所实现的算法。
这样，不计那些循环索引的递增和循环终止条件、变量声明、打印结果等操作。最终，在分析程序的运行时间时，最重要的是把程序看成是独立于程序设计语言的算法或一系列步骤。
我们在分析一个算法的运行时间时，重要的是把基本操作的数量和输入模式关联起来。
函数的渐近增长
给大家做一个测试：判断以下两个算法A和B哪个更好？
假设两个算法的输入规模都是n，算法A要做2n+3次操作，你可以这么理解：先执行n次的循环，执行完成后再有一个n次的循环，最后有3次运算。
算法B要做3n+1次操作，理解同上，你觉得它们哪一个更快些呢？
在给大家解答问题之前，先给大家做个图表参考：
| 规模 | 算法A1（2n+3） | 算法A2（2n） | 算法B1（3n+1） | 算法B2（3n） |
| n=1 | 5 | 2 | 4 | 3 |
| n=2 | 7 | 4 | 7 | 6 |
| n=3 | 9 | 6 | 10 | 9 |
| n=10 | 23 | 20 | 31 | 30 |
| n=100 | 203 | 200 | 301 | 300 |
当n=1时，算法A1效率不如算法B1，当n=2时，两者效率相同；当n>2时，算法A1就开始优于算法B1了，随着n的继续增加，算法A1比算法B1逐步拉大差距。所以总体上算法A1比算法B1优秀。
函数的渐近增长：给定两个函数f(n)和g(n)，如果存在一个整数N，使得对于所有的n>N，f(n)总是比g(n)大，那么，我们说f(n)的增长渐近快于g(n)。
从刚才的对比中我们还发现，随着n的增大，后面的+3和+1其实是不影响最终的算法变化曲线的。
例如算法A2，B2，在图中他们压根儿被覆盖了。所以，我们可以忽略这些加法常数。
后边我们给大家举多几个例子，会更明显。
第二个测试，算法C是4n+8，算法D是2n^2+1。
| 次数 | 算法C1（4n+8） | 算法C2（n） | 算法D1（2n^2+1） | 算法D2（n^2） |
| n=1 | 12 | 1 | 3 | 1 |
| n=2 | 16 | 2 | 9 | 4 |
| n=3 | 20 | 3 | 19 | 9 |
| n=10 | 48 | 10 | 201 | 100 |
| n=100 | 408 | 100 | 20001 | 10000 |
| n=1000 | 4008 | 1000 | 2000001 | 1000000 |
再来看一下线性图。
我们观察发现，哪怕去掉与n相乘的常数，两者的结果还是没有改变，算法C2的次数随着n的增长，还是远小于算法D2。
也就是说，与最高次项相乘的常数并不重要，也可以忽略。
我们再来看第三个测试，算法E是2n^2+3n+1，算法F是2n^3+3n+1。
| 次数 | 算法E1（2n^2+3n+1） | 算法E2（n^2） | 算法F1（2n^3+3n+1） | 算法F2（n^3） |
| n=1 | 6 | 1 | 6 | 1 |
| n=2 | 15 | 4 | 23 | 8 |
| n=3 | 28 | 9 | 64 | 27 |
| n=10 | 231 | 100 | 2031 | 1000 |
| n=100 | 20301 | 10000 | 2000301 | 1000000 |
再来看一下线性图。
这次我们又发现什么呢？
我们通过观察又发现，最高次项的指数大的，函数随着n的增长，结果也会变得增长特别快。
恩，我们进行最后一个小测试，把这些概念都总结起来吧！
算法G是2n^2，算法H是3n+1，算法I是 2n^+3n+1。
| 次数 | 算法G（2n^2） | 算法H（3n+1） | 算法I（2n^2+3n+1） |
| n=1 | 2 | 4 | 6 |
| n=2 | 8 | 7 | 15 |
| n=5 | 50 | 16 | 66 |
| n=10 | 200 | 31 | 231 |
| n=100 | 2000 | 301 | 20301 |
| n=1000 | 2000000 | 3001 | 200301 |
| n=10000 | 200000000 | 30001 | 200030001 |
| n=100000 | 20000000000 | 300001 | 20000300001 |
| n=1000000 | 2000000000000 | 3000001 | 2000003000001 |
看出啥？一条直线？当他们数据很小的时候是这样的：
这组数据我们看得很清楚，当n的值变得非常大的时候，3n+1已经没法和2n^2的结果相比较，最终几乎可以忽略不计。而算法G在跟算法I基本已经重合了。
于是我们可以得到这样一个结论，判断一个算法的效率时，函数中的常数和其他次要项常常可以忽略，而更应该关注主项（最高项）的阶数。
注意，判断一个算法好不好，我们只通过少量的数据是不能做出准确判断的，很容易以偏概全。
算法时间复杂度
我们说好的时间复杂度和空间复杂度呢？
历来大学老师在讲解这两个概念，都是直接登堂入室，导致八成学生对概念理解不深刻，或者说只是硬背起来而已。
为了让大家能够更好地接受这两个比较重要的概念，我们有了上一讲的准备环节。
这一讲我们直接切入正题，介绍计算复杂度的攻略，然后通过一系列例子和大家一起分析总结规律。
算法时间复杂度的定义：在进行算法分析时，语句总的执行次数T(n)是关于问题规模n的函数，进而分析T(n)随n的变化情况并确定T(n)的数量级。算法的时间复杂度，也就是算法的时间量度，记作：T(n)= O(f(n))。它表示随问题规模n的增大，算法执行时间的增长率和f(n)的增长率相同，称作算法的渐近时间复杂度，简称为时间复杂度。其中f(n)是问题规模n的某个函数。
好长好长，没想到定义这个概念的老家伙这么罗嗦。（关键需要知道执行次数==时间）
这样用大写O()来体现算法时间复杂度的记法，我们称之为大O记法。
一般情况下，随着输入规模n的增大，T(n)增长最慢的算法为最优算法。
显然，由此算法时间复杂度的定义可知，我们的三个求和算法的时间复杂度分别为O(1)，O(n)，O(n^2)。
三个求和算法？哪有？忘了？
好吧，看看以下这张图能不能勾起点回忆？
推导大O阶方法
那么如何分析一个算法的时间复杂度呢？即如何推导大O阶呢？我们给大家整理了以下攻略：
- 用常数1取代运行时间中的所有加法常数。
- 在修改后的运行次数函数中，只保留最高阶项。
- 如果最高阶项存在且不是1，则去除与这个项相乘的常数。
- 得到的最后结果就是大O阶。
世界上的东西就是这么简单，老头儿们把它讲复杂，那么它就复杂了，举几个例子：
常数阶
int sum = 0, n = 100;
printf(“I love csdn.net\n”);
printf(“I love csdn.net\n”);
printf(“I love csdn.net\n”);
printf(“I love csdn.net\n”);
printf(“I love csdn.net\n”);
printf(“I love csdn.net\n”);
sum = (1+n)*n/2;
大家觉得这段代码的大O是多少？
O(8)？这是初学者常常犯的错误，总认为有多少条语句就有多少。
分析下，按照我们的概念“T(n)是关于问题规模n的函数”来，所以我们记作O(1)就可以。
另外，如果按照攻略来，那就更简单了，攻略第一条就说明了所有加法常数给他个O(1)即可。
线性阶
一般含有非嵌套循环涉及线性阶，线性阶就是随着问题规模n的扩大，对应计算次数呈直线增长。
int i , n = 100, sum = 0;
for( i=0; i < n; i++ )
{
sum = sum + i;
}上面这段代码，它的循环的时间复杂度为O(n)，因为循环体中的代码需要执行n次。
平方阶
刚才是单个循环结构，那么嵌套呢？
int i, j, n = 100;
for( i=0; i < n; i++ )
{
for( j=0; j < n; j++ )
{
printf(“I love csdn.net\n”);
}
}
n等于100，也就是说外层循环每执行一次，内层循环就执行100次，那总共程序想要从这两个循环出来，需要执行100*100次，也就是n的平方。所以这段代码的时间复杂度为O(n^2)。
那如果有三个这样的嵌套循环呢？
没错，那就是n^3啦。所以我们很容易总结得出，循环的时间复杂度等于循环体的复杂度乘以该循环运行的次数。
刚刚我们每个循环的次数都是一样的，如果：
int i, j, n = 100;
for( i=0; i < n; i++ )
{
for( j=i; j < n; j++ )
{
printf(“I love csdn.net\n”);
}
}
惨了，老办法好像在这里套不上了，咋整？！
分析下，由于当i=0时，内循环执行了n次，当i=1时，内循环则执行n-1次……当i=n-1时，内循环执行1次，所以总的执行次数应该是：
n+(n-1)+(n-2)+…+1 = n(n+1)/2
大家还记得这个公式吧？恩恩，没错啦，就是搞死先生发明的算法丫。
那咱理解后可以继续，n(n+1)/2 = n^2/2+n/2
用我们推导大O的攻略，第一条忽略，因为没有常数相加。第二条只保留最高项，所以n/2这项去掉。第三条，去除与最高项相乘的常数，最终得O(n^2)。
对数阶
对数，属于高中数学内容啦，可能对这玩意不大理解，或者忘记了，也没事，咱分析的是程序为主，而不是数学为主，不怕。
我们看下这个程序：
int i = 1, n = 100;
while( i < n )
{
i = i * 2;
}
由于每次i*2之后，就举例n更近一步，假设有x个2相乘后大于或等于n，则会退出循环。
于是由2^x = n得到x = log(2)n，所以这个循环的时间复杂度为O(logn)。
其实理解大O推导不算难，难的是对数列的一些相关运算，这更多的是考察你的数学知识和能力。
所以这里要分两类来说下，对于想考研的朋友，需要强化一下你的数学尤其是数列方面的知识。对于想增长自己编程能力的朋友，大概知道规律即可，不要在高等数学的概念上死磕！
函数调用的时间复杂度分析
•如果我们把问题再实际化一点，大家是否能自己正确的分析出来呢？
•我们来看下边这个例子：
int i, j;
for(i=0; i < n; i++)
{
function(i);
}
void function(int count)
{
printf(“%d”, count);
}
函数体是打印这个参数，这很好理解。function函数的时间复杂度是O(1)，所以整体的时间复杂度就是循环的次数O(n)。
假如function是下面这样，又该如何呢：
void function(int count)
{
int j;
for(j=count; j < n; j++)
{
printf(“%d”, j);
}
}
事实上，这和之前我们讲解平方阶的时候举的第二个例子一样：function内部的循环次数随count的增加(接近n)而减少，所以根据游戏攻略算法的时间复杂度为O(n^2)。
尝试自己分析以下程序的时间复杂度：
n++;
function(n);
for(i=0; i < n; i++)
{
function(i);
}
for(i=0; i < n; i++)
{
for(j=i; j < n; j++)
{
printf(“%d”, j);
}
}
常见的时间复杂度
| 例子 | 时间复杂度 | 装逼术语 |
| 5201314 | O(1) | 常数阶 |
| 3n+4 | O(n) | 线性阶 |
| 3n^2+4n+5 | O(n^2) | 平方阶 |
| 3log(2)n+4 | O(logn) | 对数阶 |
| 2n+3nlog(2)n+14 | O(nlogn) | nlogn阶 |
| n^3+2n^2+4n+6 | O(n^3) | 立方阶 |
| 2^n | O(2^n) | 指数阶 |
有图有真相
常用的时间复杂度所耗费的时间从小到大依次是：O(1) < O(logn) < (n) < O(nlogn) < O(n^2) < O(n^3) < O(2^n) < O(n!) < O(n^n)
O(1),O(logn),O(n),O(n^2)我们前边已经给大家举例谈过了，至于O(nlogn)我们将会在今后的课程中介绍。
而像O(n^3)之后的这些，由于n值的增大都会使得结果大得难以想象，我们没必要去讨论它们。
最坏情况与平均情况
从心理学角度讲，每个人对将来要发生的事情都会有一个预期。譬如看半杯水，有人会说：哇哦，还有半杯哦！但有人就会失望的说：天，只有半杯了。
一般人常出于一种对未来失败的担忧，而在预期的时候趋向做最坏打算。这样，即使最糟糕的结果出现，当事人也有了心理准备，比较容易接受结果，假如结局并未出现最坏的状况，这也会使人更加快乐，瞧，事情发展的还不错嘛！嗯，这是典型的自慰手法。
算法的分析也是类似，我们查找一个有n个随机数字数组中的某个数字，最好的情况是第一个数字就是，那么算法的时间复杂度为O(1)，但也有可能这个数字就在最后一个位置，那么时间复杂度为O(n)。
平均运行时间是期望的运行时间。
最坏运行时间是一种保证。在应用中，这是一种最重要的需求，通常除非特别指定，我们提到的运行时间都是最坏情况的运行时间。
算法的空间复杂度
我们在写代码时，完全可以用空间来换去时间。
举个例子说，要判断某年是不是闰年，你可能会花一点心思来写一个算法，每给一个年份，就可以通过这个算法计算得到是否闰年的结果。
另外一种方法是，事先建立一个有2050个元素的数组，然后把所有的年份按下标的数字对应，如果是闰年，则此数组元素的值是1，如果不是元素的值则为0。这样，所谓的判断某一年是否为闰年就变成了查找这个数组某一个元素的值的问题。
第一种方法相比起第二种来说很明显非常节省空间，但每一次查询都需要经过一系列的计算才能知道是否为闰年。第二种方法虽然需要在内存里存储2050个元素的数组，但是每次查询只需要一次索引判断即可。
这就是通过一笔空间上的开销来换取计算时间开销的小技巧。到底哪一种方法好？其实还是要看你用在什么地方。
算法的空间复杂度通过计算算法所需的存储空间实现，算法的空间复杂度的计算公式记作：S(n)=O(f(n))，其中，n为问题的规模，f(n)为语句关于n所占存储空间的函数。
通常，我们都是用“时间复杂度”来指运行时间的需求，是用“空间复杂度”指空间需求。
当直接要让我们求“复杂度”时，通常指的是时间复杂度。
显然对时间复杂度的追求更是属于算法的潮流！
1569
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
