程式設計裡面估計最讓人摸不著頭腦的基本演算法就是遞迴了。很多時候我們看明白乙個複雜的遞迴都有點費時間，尤其對模型所描述的問題概念不清的時候，想要自己設計乙個遞迴那麼就更是有難度了。今天我也花費了半個小時來搞明白二叉樹的平衡性的遞迴模型，首先我不明白什麼叫做平衡性，所以花費的時候大部分實在試探理解平衡性的含義。在搞明白的時候，我突然想到假如讓我來設計，在我知道平衡性的前提下，我是否可以建立如此簡潔的遞迴模型。為此，我遇到的問題是我們到底在什麼情況下適用遞迴模型，並且遞迴模型如何建立。
數學都不差的我們，第一反應就是遞迴在數學上的模型是什麼。畢竟我們對於問題進行數學建模比起**建模拿手多了。 （當然如果對於問題很清楚的人也可以直接簡歷遞迴模型了，運用數模做中介的是針對對於那些問題還不是很清楚的人）
自己觀察遞迴，我們會發現，遞迴的數學模型其實就是歸納法，這個在高中的數列裡面是最常用的了。回憶一下歸納法。
歸納法適用於想解決乙個問題轉化為解決他的子問題，而他的子問題又變成子問題的子問題，而且我們發現這些問題其實都是乙個模型，也就是說存在相同的邏輯歸納處理項。當然有乙個是例外的，也就是遞迴結束的哪乙個處理方法不適用於我們的歸納處理項，當然也不能適用，否則我們就無窮遞迴了。這裡又引出了乙個歸納終結點以及直接求解的表示式。如果運用列表來形容歸納法就是：
步進表示式：問題蛻變成子問題的表示式
結束條件：什麼時候可以不再是用步進表示式
直接求解表示式：在結束條件下能夠直接計算返回值的表示式
邏輯歸納項：適用於一切非適用於結束條件的子問題的處理，當然上面的步進表示式其實就是包含在這裡面了。
這樣其實就結束了，遞迴也就出來了。
遞迴演算法的一般形式：
void func( mode)
else }
最典型的就是
n！演算法，這個最具有說服力。理解了遞迴的思想以及使用場景，基本就能自己設計了，當然要想和其他演算法結合起來使用，還需要不斷實踐與總結了。
例如：返回乙個二叉樹的深度：
int depth(tree t)
}判斷乙個二叉樹是否平衡：
int isb(tree t)
上面這兩個遞迴的難易程度就不一樣了，第乙個關於深度的遞迴估計只要了解遞迴思想的都可以短時間設計出來，但第二個估計就要長點時間了。純遞迴問題的難易主要糾結於一些條件表示式的構造以及初值的設定（上面的為直接表示式值的設定）。
漫談遞迴 遞迴的思想
為什麼要用遞迴 程式設計裡面估計最讓人摸不著頭腦的基本演算法就是遞迴了。很多時候我們看明白乙個複雜的遞迴都有點費時間，尤其對模型所描述的問題概念不清的時候，想要自己設計乙個遞迴那麼就更是有難度了。用歸納法來理解遞迴 數學都不差的我們，第一反應就是遞迴在數學上的模型是什麼。畢竟我們對於問題進行數學建模...
漫談遞迴 遞迴的思想 用歸納法來理解遞迴
為什麼要用遞迴 程式設計裡面估計最讓人摸不著頭腦的基本演算法就是遞迴了。很多時候我們看明白乙個複雜的遞迴都有點費時間，尤其對模型所描述的問題概念不清的時候，想要自己設計乙個遞迴那麼就更是有難度了。用歸納法來理解遞迴 數學都不差的我們，第一反應就是遞迴在數學上的模型是什麼。畢竟我們對於問題進行數學建模...
遞迴漫談（一）
遞迴，是我們在日常開發過程中經常會使用的技術。它廣泛的被現代開發語言所支援。然而，在日常的管理和招聘工作中，我發現由於開發者個人經驗不足及團隊開發規範不明確等原因，很多開發者不知道應該何時編寫遞迴函式，怎麼編寫遞迴函式。一些開發者編寫的遞迴函式存在可讀性差 除錯困難 邏輯混亂等問題，甚至還會引入死迴...