比較兩對演算法的效率

考慮問題1：已知不重複且已經按從小到大排好的m個整數的數組A[1..m]（為簡單起見。還設m=2 k，k是一個確定的非負整數）。對於給定的整數c，要求尋找一個下標i，使得A[i]=c；若找不到，則返回一個0。

問題1的一個簡單的演算法是：從頭到尾掃描數組A。照此，或者掃到A的第i個分量，經檢測滿足A[i]=c；或者掃到A的最後一個分量，經檢測仍不滿足A[i]=c。我們用一個函數Search來表達這個演算法：

Function Search (c:integer):integer;Var J:integer;BeginJ:=1; {初始化}{在還沒有到達A的最後一個分量且等於c的分量還沒有找到時，尋找下一個分量並且進行檢測}While (A[i]<c)and(j<m) doj:=j+1;If A[j]=c then search:=j {在數組A中找到等於c的分量，且此分量的下標為j}else Search:=0; {在數組中找不到等於c的分量}End;

容易看出，在最壞的情況下，這個演算法要檢測A的所有m個分量才能判斷在A中找不到等於c的分量。

解決問題1的另一個演算法利用到已知條件中A已排好序的性質。它首先拿A的中間分量A[m/2]與c比較，如果A[m/2]=c則解已找到。如果A[m/2]>c，則c只可能在A[1],A[2],..,A[m/2-1]之中，因而下一步只要在A[1], A[2], .. ，A[m/2-1]中繼續尋找；如果A[m/2]<c，則c只可能在A[m/2+1],A[m/2+2],..,A[m]之中，因而下一步只要在A[m/2+1],A[m/2+2],..,A[m]中繼續尋找。不管哪一種情形，都把下一步需要繼續尋找的範圍縮小了一半。再拿這一半的子數組的中間分量與c比較，重複上述步驟。照此重複下去，總有一個時候，或者找到一個i使得A[i]=c，或者子數組為空白（即子數組下界大於上界）。前一種情況找到了等於c的分量，後一種情況則找不到。

這個新演算法因為有反覆把供尋找的數組分成兩半，然後在其中一半繼續尋找的特徵，我們稱為二分尋找演算法。它可以用函數B_Search來表達： 

Function B_Search ( c: integer):integer;VarL,U,I : integer;  {U和L分別是要尋找的數組的下標的上界和下界}Found: boolean;BeginL:=1; U:=m;   {初始化數組下標的上下界}Found:=false; {當前要尋找的範圍是A[L]..A[U]。}{當等於c的分量還沒有找到且U>=L時，繼續尋找}While (not Found) and (U>=L) doBeginI:=(U+L) div 2;  {找數組的中間分量}If c=A[I] then Found:=Tureelse if c>A[I] then L:=I+1else U:=I-1;End;If Found then B_Search:=1else B_Search:=0;End;

容易理解，在最壞的情況下最多隻要測A中的k+1(k=logm,這裡的log以2為底，下同)個分量，就判斷c是否在A中。

演算法Search和B_Search解決的是同一個問題，但在最壞的情況下（所給定的c不在A中），兩個演算法所需要檢測的分量個數卻大不相同，前者要m=2 k個，後者只要k+1個。可見演算法B_Search比演算法Search高效得多。

以上例子說明：解同一個問題，演算法不同，則計算的工作量也不同，所需的計算時間隨之不同，即複雜性不同。

是運行這兩種演算法的時間曲線。該圖表明，當m適當大（m>m0）時，演算法B_Search比演算法Search省時，而且當m更大時，節省的時間急劇增加。

不過，應該指出：用執行個體的已耗用時間來度量演算法的時間複雜性並不合適，因為這個執行個體時間與運行該演算法的實際電腦效能有關。換句話說，這個執行個體時間不單純反映演算法的效率而是反映包括運行該演算法的電腦在內的綜合效率。我們引入演算法複雜性的概念是為了比較解決同一個問題的不同演算法的效率，而不想去比較運行該演算法的電腦的效能。因而，不應該取演算法啟動並執行執行個體時間作為演算法複雜性的尺度。我們希望，盡量單純地反映作為演算法精髓的計算方法本身的效率，而且在不實際運行該演算法的情況下就能分析出它所需要的時間和空間。