FeBull

來源: MMDays專欄

Posted By Mr. Thursday & Mr. Saturday
(註：本篇文章有一點長，請耐心服用 XD)

想像一下，我剛才說了一句話，那句話是：「想像一下，我剛才說了一句話，那句話是：「想像一下，我剛才說了一句話，那句話是：……….」」，如此下去，就好像站在兩面平行擺設的鏡子中間，鏡子中的影像不斷的重複。再舉個例子，寫完一封信想要匿名保密，就署名「知名不具」。回信的人寫：「知 知名不具 具」。之後再回信的時候就變成：知知知名不具具具，加上括號可能比較清楚：(知(知(知名不具)具)具)。

遞迴就是類似這樣子，不斷的重複同樣的東西，只不過每次重複的是比較小的東西了。大家應該對數學歸納法不陌生，在使用數學歸納法時，我們首先確定 n=1 的時候某件事情是成立，然後在證明 n 到 n+1 的過程是正確的，就可以從 n=1 的例子，一路推論出第 n 項是甚麼東西。就像是推骨牌一樣，把第一張牌推倒了之後，剩下的骨牌自然就被前面的骨牌給推倒。

遞迴的概念則是相反的方向：我們想要解決一個大小為 n 的問題，我首先做的事情是把問題化簡成大小為 n-1 的問題，但是解決的方法還是一樣，只不過大小是 n-1。如此繼續化簡，最後變成大小為 n=1 的基本問題，接著只要n=1的基本問題解決了，原來大小為n的問題也跟著解決了。

這又好像層層分工。假設每個人都會加法，然後今天我想求出 1+2+…+n 等於多少？其中一個辦法就是遞迴，我先假設 1+2+…+(n-1) 已經有人算好，那麼我只要再加上 n，就可以得到答案了。然而 1+2+…+(n-1) 要怎麼得到呢？我就請另外一位朋友幫我算。另外一位朋友接到這個問題以後，也用同樣的方法，他把 1+2+…+(n-2) 的結果交給另外一位朋友算，然後把這個結果加上 (n-1)，就變成我想要的 1+2+…+(n-1) 了。朋友的朋友也繼續用類似的方法，直到最後一位朋友只需要回答1，接著倒數第二位朋友就把1加上2，傳給倒數第三位朋友，倒數第三位朋友加上3，一直到我收到 1+2+…+(n-1) 的結果，再加上 n，就大功告成了。

不過可能會覺得，如此簡單的問題，為何還需要遞迴呢？其實遞迴也是比較適合一些問題來解，也就是那些「解決方式一樣，但是可以化成大小比較小」的問題，除此之外還可以輕鬆解決基本問題(n=1的時候)。舉例來說，有個古老的問題叫做河內塔 (Hanoi Tower)，問題的定義引述如下 (引述網站)

1883年，一位法國的數學家 Edouard Lucas 教授在歐洲的一份雜誌上介紹了一個相當吸引人的難題──迷人的智力遊戲。這個遊戲名為河內塔 (Tower of Hanoi)，它源自古印度神廟中的一段故事 (也有一說是 Lucas 教授為增加此遊戲之神秘色彩而捏造的)。傳說在古老的印度，有一座神廟，據說它是宇宙的中心。在廟宇中放置了一塊上面插有三根長木釘的木板，在其中的一根木釘上，從上至下被放置了64片直徑由小至大的圓環形金屬片。古印度教的天神指示祂的僧侶們將64片的金屬片移至三根木釘中的其中一根上。規定在每次的移動中，只能搬移一片金屬片，並且在過程中必須保持金屬片由上至下是直徑由小至大的次序，也就是說不論在那一根木釘上，圓環形的金屬片都是直徑較小的被放在上層。直到有一天，僧侶們能將64片的金屬片依規則從指定的木釘上全部移動至另一根木釘上，那麼，世界末日即隨之來到，世間的一切終將被毀滅，萬物都將至極樂世界。

倘若這個故事的敘述為真，那麼，我們只需加速移動金屬片，是不是就能愈早到達極樂世界呢？果真要移動這64片金屬片，那麼，至少要花幾次的搬動才能完成呢？有沒有規律可循呢？

這個問題，就很符合剛才的特性：我們可以把大問題化成小問題，而且解決的方法相同，只不過問題的大小變小了。另外基本問題(n=1)，就是移動一根金屬片所需要的次數，這個我們也可以輕易解決，所以這個問題就可以用遞迴來解。

首先，我們假設有A、B、C三根柱子，這64片金屬片一開始在柱子A上面，我們想要搬到柱子C。因為問題中規定某個金屬片上面是空的時候才能移動，我們就假設有個人可以幫我們把63片比較小的金屬片先從柱子A搬到柱子B上面，然後我們把最大的那一片從柱子A搬到柱子C，再請那位朋友把剛才的63片從柱子B搬到柱子C，整個問題就解決了。然後我們只要知道剛才那位朋友搬了幾次，然後加上我們自己般動的1次，就是整個問題要求的搬動次數了。

遞迴不僅僅在數學上有其重要性，在電腦科學之中扮演的角色更是至關重要。程式設計者對於遞迴絕對不會陌生，上面所舉的河內塔問題，實際上也是電腦科學的經典例子之一，是初學程式設計的人一定會學到的東西。遞迴的思維，常常可以讓程式設計者打造出簡潔的程式，讓繁冗的問題透過簡單的程式碼來解決 (例如 parser 的設計)。演算法上所講的 dynamic programming，就是遞迴思維在演算法的具體呈現。

遞迴同時也是碎形 (fractal) 這門大學問的基石，碎形是一種相當美妙的幾何圖案，就如同上面那一張蒙娜麗莎的圖一樣，圖中有圖，形中有形，且小的部分都是大的部分的縮影，我們就稱之為碎形。碎形本身的數學定義，實際上就包含了遞迴定義在裡面，我們甚至於可以說，碎形是遞迴在幾何學的一種具體呈現。但是碎形不僅僅是一種數學概念而已，在自然界中，有許許多多的地方都出現自然的碎形，讓人讚嘆遞迴原來就出現在我們的生活周圍。圖中的這棵花椰菜，就蘊含了遞迴的碎形圖案與於其中。碎形同時也在各個研究領域有著廣泛的應用，光是在電腦科學領域，就有人把碎形應用在影像和影片壓縮之上 (這不難想像，由於碎形這種以小見大的特性，我們可以用小的來表現大的，因此可以有壓縮的概念出現)，在電腦圖學上 (computer graphics)，也有人把碎形應用在設計電腦遊戲之中的一些景物，打造出有效率和簡潔的系統。現在電腦遊戲之中的景物，很多都是玩家邊玩、遊戲系統邊產生出即時的景物，這叫做 procedural generation，這種即時產生景物的技術，可以避免遊戲軟體預先儲存一堆要展現的景物，幫整個軟體瘦身。procedural generation 就使用了大量的碎形產生與合成技術於其中，而這些都根植於遞迴這一個深刻卻簡單的思維。

至於把碎形應用在遊戲之中，現在已經做到有多可怕的地步了呢？請大家看看以下的三張圖片，不妨猜猜擁有這種精緻畫面的遊戲軟體，其整個遊戲的size大小是多少呢？

正確答案是97KB！沒錯，我沒有打錯字，你的眼睛也沒有看錯，這款遊戲的大小只有 97KB！傳統的一片 3.5 吋磁片可以裝下十幾個這款遊戲！這一款第一人稱的射擊遊戲叫做 .kkrieger，是由德國的 demogroup .theprodukkt 所開發，截至目前為止還在beta測試版的階段，這款遊戲之所以可以壓縮到這麼小的境界，就是因為遊戲之中的場景和音樂幾乎全部都是由動態產生，遊戲之中預先存放的資料只有一些簡單的幾何形狀和 MIDI 音樂檔，所以自然檔案大小非常小。如果這款遊戲沒有用 procedural generation 的技巧進來的話，估計檔案大小會爆增成 200~300MB，這樣的技術，真是令人嘆為觀止。而背後最大的功臣，就是這篇文章談到的遞迴和碎形。各位也不妨下載來玩玩看吧 (下載點)。不過需要注意到一件事情，這款遊戲的載入時間非常長，因為他要靠著一點點的程式碼即時來運算製造出場景，所以要耗去很多計算時間，這可說是一種 time 和 space 的 tradeoff。

看完這篇文章，各位有沒有對看似枯燥的數學有了一點點不同的看法呢？沒想到遞迴可以這樣應用在遊戲開發之中吧。下次學習數學感覺到枯燥時，不妨從應用的角度切入試試看吧！