随笔：估算程序算法复杂度的理解

大体分为：事前估算(设计算法之前就估算此算法性能)和事后估算(运行后，通过收集数据)

直觉上以为是事后估算为主，毕竟，实践是检验真理的标准嘛。事后收集数据才是比较靠谱的。

 

不过，想法错了。现在才明白，以"事前估算"为主要办法。

为什么事后估算的办法不怎么使用呢？

1、输入的数据量没法真实模拟。比如输入的数据量是100，两种算法之间并不明显差异。而输入的数据量是100万的时候，才会看到明显的差异。但在我们的实验环境下，很难做到这么真实的测验，缺乏这种环境。如果都放到事后去估算，因为没法真实测验，那就会很麻烦。

我的一个实际感受是，在数据库测验中，即便我们在实验环境下，可以模拟输入100万行数据，我只有5个字段的行。但在真实的应用环境下，100万数据又比这复杂些。会有10个字段的行。

2、受制于硬件环境。两种算法，a算法比b算法好。但b算法是在性能优越的机器上测验，所以没看出比a算法差在哪里，结果是两个算法看不出明显的差别。

最终，硬件好可以掩盖比较劣质的算法,劣的算法看不出有多劣质。

 

那是不是说，让两种算法在同样的机器上来测验就ok了呢？我也尝试寻找对这个疑惑的解释，留在这里。有质疑才会有进步

 找到了解释，即便在同样的机器上来进行测试，但由于计算机的内存使用率、cpu使用率是动态变化的,使用情况不同，造成的测试结果也会不同。

 

 

事前估算主要跟数据输入量、运行次数两个因素有关。

 

 了解几个术语与符号表示,因为业界都是这些术语与符号来描述，如果不清楚，就难以看懂他们的要表达的意思

T(n)

f(n)

 

有些解释太文绉绉了，绕来绕去，我没怎么理解。

算法的时间复杂度记做：T(n)=O(f(n));

 

我的理解：

 

T是英文单词的time的简写，T(n)表示算法要执行的时间耗费。

F应该是，Frequency Count的简称。理解为次数的意思。

每条语句的执行时间=语句的执行次数(即频度(Frequency Count))×语句执行一次所需时间。

每条语句就是程序中的一句代码。比如一句代码习惯用分号"；"来结束。这个我觉得不必纠结很细。可以是一个函数的调用，如果在for循环中，只算多少次循环就可以了。

 

计算一个算法的复杂度分为两个方面：时间复杂度和空间复杂度。

时间复杂度，就是执行这个算法需要耗费多长时间，这是通俗解释了。

空间复杂度，就是执行这个算法需要多少内存空间(因为最终计算都是在内存中进行，不是在磁盘中)

先不需要了解如何计算一个算法耗费多少内存，看看需要执行多长时间，怎么计算

 

下面解释了缘由：

一个算法执行所耗费的时间，从理论上是不能算出来的，必须上机运行测试才能知道。但我们不可能也没有必要对每个算法都上机测试，只需知道哪个算法花费的时间多，哪个算法花费的时间少就可以了。并且一个算法花费的时间与算法中语句的执行次数成正比例，哪个算法中语句执行次数多，它花费时间就多。一个算法中的语句执行次数称为语句频度或时间频度。

 

 

我喜欢上面这么通俗的解释，意思是，测验一个算法是时间复杂度，可靠的办法是对运行期间执行的操作次数进行统计，因为操作次数越多，耗费的时间肯定越多。

算法的准确执行时间算不出来(因为在不同硬件、内存占有情况下执行时间不同)，只能通过运行次数来间接判断(这样抛开了硬件环境等影响)。执行次数越多的算法肯定越不好。

 

   于是：时间复杂度计算，变成了对执行次数进行统计。那怎么统计执行次数，用什么来表示呢？

   用f(n)来表示：输入量为n的情况下，执行次数是多少。f(n)是一个函数。

 

    关于函数的渐近增长的理解：f(n)的渐近增长大于g(n)，就是表示随着n输入值变大,f算法的执行次数要大于g算法，所以渐近增长值越大，算法越不好。

 

    最终：根据"测验时间复杂度最终是测验执行次数"这个方式，我们只要测量f(n)的情况，就能侧面测验时间复杂度T(n)了。

 

   T(n)=0(f(n))           时间复杂度常用大O符号表述

  表示，算法执行时间的增长率和f(n)的增长率相同。这里面相同业界命了一个名称，渐近时间复杂度，简称为时间复杂度。

  可以看出，这个时间复杂度，是一个近似的值，就像命名那样子，渐近(的)时间复杂度。

 

 

  总结：事前估算法，能够做到抛开硬件、软件因素影响算法的测验。