數據結構與算法的重溫之旅（八）——遞歸

接下來說的是算法是遞歸。在講遞歸前咱們先舉個遞歸的例子。在軍訓中教官可能會喊道讓隊員叫號，對18號出列，若是隊員彼此都不知作別人甚至本身的號碼，處於徹底隨機的排隊狀態的話，那麼這個時候叫號其實至關於一個遞歸，即當前一個叫號的時候，我知道前一我的和本身的號碼。

那什麼是遞歸呢？即函數本身調用本身就是一個遞歸。可是若是函數一直調用本身的話則有可能會出現堆棧溢出致使程序崩潰，因此嚴格來講，遞歸除了本身可以調用本身自己之外，還要知足三個必要的條件。

首先第一個是一個問題的解能夠分解爲幾個子問題的解。像上面講的例子第十八號出列，能夠分解成前一我的的號碼是多少的問題。

第二就是這個問題與分解以後的子問題除了數據規模不一樣之外，求解思路都是同樣的。就好像上面的例子，你只有當前一我的喊到幾，你才知道本身是第幾號，而子問題求解的也是求解前一我的喊到幾，因此思路是同樣的。

第三點就是遞歸必定要有一個終止條件。仍是用教官叫號的例子，教官所培訓的人確定是有限，因此當教官喊的號太大，叫到最後一我的的時候教官就知道本身喊的號太大了。而若是教官喊的號恰好在範圍時，他就知道哪一個人是十八號。這個就是遞歸終止條件。

說了這麼多，那咱們如何編寫一個遞歸呢？其實寫一個遞歸的關鍵是寫出這個遞歸的遞歸公式和終止條件，而後經過程序來實現該遞歸公式。

假如這裏有 n 個臺階，每次你能夠跨 1 個臺階或者 2 個臺階，請問走這 n 個臺階有多少種走法？若是有 7 個臺階，你能夠 2，2，2，1 這樣子上去，也能夠 1，2，1，1，2 這樣子上去，總之走法有不少，那如何用編程求得總共有多少種走法呢？咱們仔細想下，實際上，能夠根據第一步的走法把全部走法分爲兩類，第一類是第一步走了 1 個臺階，另外一類是第一步走了 2 個臺階。因此 n 個臺階的走法就等於先走 1 階後，n-1 個臺階的走法 加上先走 2 階後，n-2 個臺階的走法。用公式表示就是：

有了這個遞歸公式以後咱們再來分析一下終止條件。n=2 時，f(2)=f(1)+f(0)。若是遞歸終止條件只有一個 f(1)=1，那 f(2) 就沒法求解了。因此除了 f(1)=1 這一個遞歸終止條件外，還要有 f(0)=1，表示走 0 個臺階有一種走法，不過這樣子看起來就不符合正常的邏輯思惟了。因此，咱們能夠把 f(2)=2 做爲一種終止條件，表示走 2 個臺階，有兩種走法，一步走完或者分兩步來走。

因此，遞歸終止條件就是 f(1)=1，f(2)=2。這個時候，你能夠再拿 n=3，n=4 來驗證一下，這個終止條件是否足夠而且正確。咱們把遞歸終止條件和剛剛獲得的遞推公式放到一塊兒就是這樣的：

有了公式之後咱們編寫代碼就容易多了：

function func(val){
    if (val === 1) return 1
    if (val === 2) return 2
    return func(val - 1) + func(val - 2)
}複製代碼

總結一下，寫遞歸代碼的關鍵就是找到如何將大問題分解爲小問題的規律，而且基於此寫出遞推公式，而後再推敲終止條件，最後將遞推公式和終止條件，最後將遞推公式和終止條件翻譯成代碼。

其實每一個人以爲遞歸難主要是鑽進了一個思惟慣性中，好比上面的定義所說遞歸是要將大的問題分解成更細的子問題，若是是像上面叫號那樣只是不斷的分解出一個子問題的話就比較容易理解，若是像走石階那樣分解成兩個子問題則開始比較難理解了。其實人腦幾乎沒辦法把整個「遞」和「歸」的過程一步一步都想清楚。計算機擅長作重複的事情，因此遞歸正和它的胃口。而咱們人腦更喜歡平鋪直敘的思惟方式。當咱們看到遞歸時，咱們總想把遞歸平鋪展開，腦子裏就會循環，一層一層往下調，而後再一層一層返回，試圖想搞清楚計算機每一步都是怎麼執行的，這樣就很容易被繞進去。

對於遞歸代碼，這種試圖想清楚整個遞和歸過程的作法，其實是進入了一個思惟誤區。不少時候，咱們理解起來比較吃力，主要緣由就是本身給本身製造了這種理解障礙。那正確的思惟方式應該是怎樣的呢？若是一個問題 A 能夠分解爲若干子問題 B、C、D，你能夠假設子問題 B、C、D 已經解決，在此基礎上思考如何解決問題 A。並且，你只須要思考問題 A 與子問題 B、C、D 兩層之間的關係便可，不須要一層一層往下思考子問題與子子問題，子子問題與子子子問題之間的關係。屏蔽掉遞歸細節，這樣子理解起來就簡單多了。

所以，編寫遞歸代碼的關鍵是，只要遇到遞歸，咱們就把它抽象成一個遞推公式，不用想一層層的調用關係，不要試圖用人腦去分解遞歸的每一個步驟。

除此以外像上面說的，咱們編寫遞歸代碼的時候要避免堆棧溢出。我在「棧」那一節講過，函數調用會使用棧來保存臨時變量。每調用一個函數，都會將臨時變量封裝爲棧幀壓入內存棧，等函數執行完成返回時，纔出棧。系統棧或者虛擬機棧空間通常都不大。若是遞歸求解的數據規模很大，調用層次很深，一直壓入棧，就會有堆棧溢出的風險。

咱們能夠經過在代碼中限制遞歸調用的最大深度的方式來解決這個問題。遞歸調用超過必定深度（好比 1000）以後，咱們就不繼續往下再遞歸了，直接返回報錯。仍是電影院那個例子，咱們能夠改形成下面這樣子，就能夠避免堆棧溢出了。

let deep = 0
function func(val){
    ++n
    if (n > 1000) return throw Error('error')
    if (val === 1) return 1
    if (val === 2) return 2
    return func(val - 1) + func(val - 2)
}複製代碼

但這種作法並不能徹底解決問題，由於最大容許的遞歸深度跟當前線程剩餘的棧空間大小有關，事先沒法計算。若是實時計算，代碼過於複雜，就會影響代碼的可讀性。因此，若是最大深度比較小，好比 十、50，就能夠用這種方法，不然這種方法並非很實用。

還有一點就是避免遞歸的重複運算。就拿上面走階梯的爲例，若是計算一個f(5)，首先第一步你要算出f(4)和f(3)，而後第二步經過f(4)算出f(3)和f(2)，第三步這裏的f(3)還要繼續算出f(2)和f(1)。可是這裏的第一步的f(3)卻尚未算，須要重複第三步的步驟再算一遍。f(5)還好只是重複了一個，若是n越大，則重複的機率則越大。這個時候咱們能夠經過一個散列表或者是其餘可以表示惟一的數據結構來儲存n爲幾的時候的值。在JavaScript中則能夠經過Set來儲存。代碼以下：

var tempIndex = new Set()
var tempValue = []

function f(n) {
    if (n == 1) return 1;
    if (n == 2) return 2;

    if (tempIndex.has(n)) {
        return tempValue[n];
    }

    var ret = f(n-1) + f(n-2);
    tempIndex.add(n)
    tempValue[n] = ret
    return ret;
}複製代碼

在時間效率上，遞歸代碼裏多了不少函數調用，當這些函數調用的數量較大時，就會積聚成一個可觀的時間成本。在空間複雜度上，由於遞歸調用一次就會在內存棧中保存一次現場數據，因此在分析遞歸代碼空間複雜度時，須要額外考慮這部分的開銷，好比咱們前面講到的教官叫號，空間複雜度並非 O(1)，而是 O(n)。

那遞歸的時間複雜度那麼高，而且還會存在堆棧溢出和重複計算的風險，那咱們如何去將遞歸改寫成非遞歸代碼呢？那剛剛所說到的例子，這條式子其實只是表示當前函數等於當前函數的上一個值家當前函數的上上一個值，那麼咱們能夠用循環來從一開始迭代上去：

function f(n) {
  if (n == 1) return 1;
  if (n == 2) return 2;
  
  var ret = 0;
  var pre = 2;
  var prepre = 1;
  for (var i = 3; i <= n; ++i) {
    ret = pre + prepre;
    prepre = pre;
    pre = ret;
  }
  return ret;
}
複製代碼

再好比這條式子，表示的是當前函數值等於當前函數的上一個值加1，這個實現起來就更簡單了：

function f(n) {
  var ret = 1;
  for (var i = 2; i <= n; ++i) {
    ret = ret + 1;
  }
  return ret;
}
複製代碼

那是否是全部的遞歸代碼均可以改成這種迭代循環的非遞歸寫法呢？籠統地講，是的。由於遞歸自己就是藉助棧來實現的，只不過咱們使用的棧是系統或者虛擬機自己提供的，咱們沒有感知罷了。若是咱們本身在內存堆上實現棧，手動模擬入棧、出棧過程，這樣任何遞歸代碼均可以改寫成看上去不是遞歸代碼的樣子。可是這種思路其實是將遞歸改成了「手動」遞歸，本質並無變，並且也並無解決前面講到的某些問題，徒增了實現的複雜度。

上一篇文章：數據結構與算法的重溫之旅（七）——隊列​​​​​​​

下一篇文章：數據結構與算法的重溫之旅（九）——三個簡單的排序算法​​​​​​​ 

延伸閱讀：數據結構與算法的重溫之旅（番外篇1）——談談斐波那契數列​​​​​​​