㈠ python-027-遞歸-求序列最大值、計算第n個調和數、轉換字元到整數
遞歸，emmmmmmm，擁有一種魅力，接近人的立即思維，容易理解，又不容易理解。
遞歸演算法的優點： 它使我們能夠簡潔地利用重復結構呈現諸多問題。通過使演算法描述以遞歸的方式利用重復結構，我們經常可以避開復雜的案例分析和嵌套循環。這種演算法會得出可讀性更強的演算法描述，而且十分有效。
但是 ，遞歸的使用要根據相應的成本來看，每次遞歸python解釋器都會給一個空間來記錄函數活動狀態。但是有時候內存成本很高，有時候將遞歸演算法轉為非遞歸演算法是一種好辦法。
當然我們可以換解釋器、使用堆棧數據結構等方法，來管理遞歸的自身嵌套，減小儲存的活動信息，來減小內存消耗。
最近演算法學到了遞歸這一塊，寫了三個課後習題：
給一個序列S，其中包含n個元素，用遞歸查找其最大值。
輸出：
調和數：Hn = 1 + 1/2 + 1/3 + ··· + 1/n
輸出：
例如："12345"<class 'str'> 轉換為12345<class 'int'>
輸出：
遞歸分為線性遞歸、二路遞歸、多路遞歸。
㈡ C語言的遞歸好難理解，誰能詳細解釋下
<可以自由轉載，但請註明以下內容，謝謝合作！>
<作者：Enoch Wang 引用自：http://chinawangquan.spaces.live.com>
所謂遞歸，簡而言之就是應用程序自身調用自身，以實現層次數據結構的查詢和訪問。 遞歸的使用可以使代碼更簡潔清晰，可讀性更好（對於初學者到不見得），但由於遞歸需要系統堆棧，所以空間消耗要比非遞歸代碼要大很多，而且，如果遞歸深度太大，可能系統資源會不夠用。
往往有這樣的觀點：能不用遞歸就不用遞歸，遞歸都可以用迭代來代替。
誠然，在理論上，遞歸和迭代在時間復雜度方面是等價的（在不考慮函數調用開銷和函數調用產生的堆棧開銷），但實際上遞歸確實效率比迭代低，既然這樣，遞歸沒有任何優勢，那麼是不是就，沒有使用遞歸的必要了，那遞歸的存在有何意義呢？
萬物的存在是需要時間的檢驗的，遞歸沒有被歷史所埋沒，即有存在的理由。從理論上說，所有的遞歸函數都可以轉換為迭代函數，反之亦然，然而代價通常都是比較高的。但從演算法結構來說，遞歸聲明的結構並不總能夠轉換為迭代結構，原因在於結構的引申本身屬於遞歸的概念，用迭代的方法在設計初期根本無法實現，這就像動多態的東西並不總是可以用靜多態的方法實現一樣。這也是為什麼在結構設計時，通常採用遞歸的方式而不是採用迭代的方式的原因，一個極典型的例子類似於鏈表，使用遞歸定義及其簡單，但對於內存定義(數組方式)其定義及調用處理說明就變得很晦澀，尤其是在遇到環鏈、圖、網格等問題時，使用迭代方式從描述到實現上都變得不現實。 因而可以從實際上說，所有的迭代可以轉換為遞歸，但遞歸不一定可以轉換為迭代。
採用遞歸演算法需要的前提條件是，當且僅當一個存在預期的收斂時，才可採用遞歸演算法，否則，就不能使用遞歸演算法。
遞歸其實是方便了程序員難為了機器，遞歸可以通過數學公式很方便的轉換為程序。其優點就是易理解，容易編程。但遞歸是用棧機制實現的，每深入一層，都要佔去一塊棧數據區域，對嵌套層數深的一些演算法，遞歸會力不從心，空間上會以內存崩潰而告終，而且遞歸也帶來了大量的函數調用，這也有許多額外的時間開銷。所以在深度大時，它的時空性就不好了。
而迭代雖然效率高，運行時間只因循環次數增加而增加，沒什麼額外開銷，空間上也沒有什麼增加，但缺點就是不容易理解，編寫復雜問題時困難。
因而，「能不用遞歸就不用遞歸，遞歸都可以用迭代來代替」這樣的理解，Enoch不敢苟同，還是辯證的來看待，不可一棍子打死。
參考資料：http://chinawangquan.spaces.live.com/blog/cns!9CF795352E94BF70!787.entry