寫遞歸函數的正確思維方法

遞歸是編程中一個相對難以理解但是卻又很重要的概念. 對於從命令式語言開始學習編程的程序員天生對此有理解缺陷, 而對於從類似C++這種對函數式編程範式不友好的語言開始學習編程的程序員就更加如此了.(比如我自己) 碰巧(其實不巧)最近在讀這本書(這本書國內沒有引進, 網上只有巨貴的亞馬遜賣的原版, 我讀的是網上的中文版), Paul Graham在書中講述的如何寫遞歸函數的部分, 讓我印象深刻. 因爲原書是講Lisp的, 當然這個部分也是用Lisp作爲例子描述的, 考慮到國內會看這本書的人太少, 能看懂Lisp的就更不多了, 我這裏根據自己的理解, 重新整理一下. 最重要的是, 書中原來的例子太少, 太簡單, 我自己提供了一些額外的, 並且更加複雜的例子. 以期對問題能有更好的理解.

什麼是遞歸

迭代的是人，遞歸的是神
–L. Peter Deutsch

簡單的定義: “當函數直接或者間接調用自己時，則發生了遞歸.” 說起來簡單, 但是理解起來複雜, 因爲遞歸併不直觀, 也不符合我們的思維習慣, 相對於遞歸, 我們更加容易理解迭代. 因爲我們日常生活中的思維方式就是一步接一步的, 並且能夠理解一件事情做了N遍這個概念. 而我們日常生活中幾乎不會有遞歸思維的出現.
舉個簡單的例子, 即在C/C++中計算一個字符串的長度. 下面是傳統的方式, 我們一般都這樣通過迭代來計算長度, 也很好理解.

size_t length(const char *str) {
  size_t length = 0;
  while (*str != 0) {
    ++length;
    ++str;
  }

  return length;
}

而事實上, 我們也可以通過遞歸來完成這樣的任務.

size_t length(const char *str) {
  if (*str == 0) {
    return 0;
  }
  return length(++str) + 1;
}

只不過, 我們都不這麼做罷了, 雖然這樣的實現有的時候可能代碼更短, 但是很明顯, 從思維上來說更加難以理解一些. 當然, 我是說假如你不是習慣於函數式語言的話. 這個例子相對簡單, 稍微看一下還是能明白吧.
迭代的算法可以這樣描述: 從第一個字符開始判斷字符串的每一個字符, 當該字符不爲0的時候, 該字符串的長度加一.
遞歸的算法可以這樣描述: 當前字符串的長度等於當前字符串除了首字符後, 剩下的字符串長度+1.
作爲這麼簡單的例子, 兩種算法其實大同小異, 雖然我們習慣迭代, 但是, 也能看到, 遞歸的算法無論是從描述上還是實際實現上, 並不比迭代要麻煩.

理解遞歸

在初學遞歸的時候, 看到一個遞歸實現, 我們總是難免陷入不停的回溯驗證之中, 因爲回溯就像反過來思考迭代, 這是我們習慣的思維方式, 但是實際上遞歸不需要這樣來驗證. 比如, 另外一個常見的例子是階乘的計算. 階乘的定義: “一個正整數的階乘（英語：factorial）是所有小於或等於該數的正整數的積，並且0的階乘爲1。” 以下是Ruby的實現:

def factorial(n) 
  if n <= 1 then
    return 1
  else
    return n * factorial(n - 1)
  end
end

我們怎麼判斷這個階乘的遞歸計算是否是正確的呢? 先別說測試, 我說我們讀代碼的時候怎麼判斷呢?
回溯的思考方式是這麼驗證的, 比如當n = 4時, 那麼factoria(4)等於4 * factoria(3), 而factoria(3)等於3 * factoria(2), factoria(2)等於2 * factoria(1), 等於2 * 1, 所以factoria(4)等於4 * 3 * 2 * 1. 這個結果正好等於階乘4的迭代定義.
用回溯的方式思考雖然可以驗證當n = 某個較小數值是否正確, 但是其實無益於理解.
Paul Graham提到一種方法, 給我很大啓發, 該方法如下:

1. 當n=0, 1的時候, 結果正確.
2. 假設函數對於n是正確的, 函數對n+1結果也正確.
   如果這兩點是成立的，我們知道這個函數對於所有可能的n都是正確的。

這種方法很像數學歸納法, 也是遞歸正確的思考方式, 事實上, 階乘的遞歸表達方式就是1!=1，n!=(n-1)!×n(見wiki). 當程序實現符合算法描述的時候, 程序自然對了, 假如還不對, 那是算法本身錯了…… 相對來說, n,n+1的情況爲通用情況, 雖然比較複雜, 但是還能理解, 最重要的, 也是最容易被新手忽略的問題在於第1點, 也就是基本用例(base case)要對. 比如, 上例中, 我們去掉if n <= 1的判斷後, 代碼會進入死循環, 永遠不會結束.

使用遞歸

既然遞歸比迭代要難以理解, 爲啥我們還需要遞歸呢? 從上面的例子來看, 自然意義不大, 但是很多東西的確用遞歸思維會更加簡單……
經典的例子就是斐波那契數列, 在數學上, 斐波那契數列就是用遞歸來定義的:

·F0 = 0
·F1 = 1 
·Fn = Fn – 1 + Fn – 2

有了遞歸的算法, 用程序實現實在再簡單不過了:

def fibonacci(n)
  if n == 0 then
    return 0
  elsif n == 1 then
    return 1
  else
    return fibonacci(n - 1) + fibonacci(n - 2)
  end
end

改爲用迭代實現呢? 你可以試試.
上面講了怎麼理解遞歸是正確的, 同時可以看到在有遞歸算法描述後, 其實程序很容易寫, 那麼最關鍵的問題就是, 我們怎麼找到一個問題的遞歸算法呢?
Paul Graham提到, 你只需要做兩件事情:

1. 你必須要示範如何解決問題的一般情況, 通過將問題切分成有限小並更小的子問題.
2. 你必須要示範如何通過有限的步驟, 來解決最小的問題(基本用例).
   如果這兩件事完成了, 那問題就解決了. 因爲遞歸每次都將問題變得更小, 而一個有限的問題終究會被解決的, 而最小的問題僅需幾個有限的步驟就能解決.

這個過程還是數學歸納法的方法, 只不過和上面提到的一個是驗證, 一個是證明.
現在我們用這個方法來尋找漢諾塔這個遊戲的解決方法.(這其實是數學家發明的遊戲)

有三根杆子A，B，C。A杆上有N個(N>1)穿孔圓盤，盤的尺寸由下到上依次變小。要求按下列規則將所有圓盤移至C杆：
1.每次只能移動一個圓盤.
2.大盤不能疊在小盤上面.

這個遊戲在只有3個盤的時候玩起來較爲簡單, 盤越多, 就越難, 玩進去後, 你就會進入一種不停的通過回溯來推導下一步該幹什麼的狀態, 這是比較難的. 我記得第一次碰到這個遊戲好像是在大航海時代某一代遊戲裏面, 當時就覺得挺有意思的. 推薦大家都實際的玩一下這個遊戲, 試試你腦袋能想清楚幾個盤的情況.
現在我們來應用Paul Graham的方法思考這個遊戲.

一般情況:
當有N個圓盤在A上, 我們已經找到辦法將其移到C槓上了, 我們怎麼移動N+1個圓盤到C槓上呢? 很簡單, 我們首先用將N個圓盤移動到C上的方法將N個圓盤都移動到B上, 然後再把第N+1個圓盤(最後一個)移動到C上, 再用同樣的方法將在B槓上的N個圓盤移動到C上. 問題解決.

基本用例:
當有1個圓盤在A上, 我們直接把圓盤移動到C上即可.

算法描述大概就是上面這樣了, 其實也可以看作思維的過程, 相對來說還是比較自然的. 下面是Ruby解:

def hanoi(n, from, to, other)
  if n == 1 then
    puts from + ' -> ' + to
  else
    hanoi(n-1, from, other, to)
    hanoi(1, from, to, other)
    hanoi(n-1, other, to, from)
  end
end

當n=3時的輸出:

A -> C
A -> B
C -> B
A -> C
B -> A
B -> C
A -> C

上述代碼中, from, to, other的作用其實也就是提供一個杆子的替代符, 在n=1時, 其實也就相當於直接移動. 看起來這麼複雜的問題, 其實用遞歸這麼容易, 沒有想到吧. 要是想用迭代來解決這個問題呢? 還是你自己試試吧, 你試的越多, 就能越體會到遞歸的好處.

遞歸的問題

當然, 這個世界上沒有啥時萬能的, 遞歸也不例外, 首先遞歸併不一定適用所有情況, 很多情況用迭代遠遠比用遞歸好了解, 其次, 相對來說, 遞歸的效率往往要低於迭代的實現, 同時, 內存好用也會更大, 雖然這個時候可以用尾遞歸來優化, 但是尾遞歸並不是一定能簡單做到.

參考

1. Ansi Common Lisp
2. 精通遞歸程序設計 

writen by 九天雁翎(www.jtianling.com)