遞歸演算法缺點

Ⅰ 一個遞歸演算法必須包括什麼

遞歸演算法包含的兩個部分：

1、由其自身定義的與原始問題類似的更小規模的子問題（只有數據規模不同），它使遞歸過程持續進行，稱為一般條件。

2、所描述問題的最簡單的情況，它是一個能控制遞歸過程結束的條件，稱為基本條件。（遞歸出口）

遞歸的定義：

如果一個對象部分地由它自身組成或按它自己定義，則稱它是遞歸的，所以說遞歸就是函數/過程/子過程在運行過程中直接或間接調用自身而產生的重入現象。

遞歸的基本思想：

就是把一個規模大的問題分為若干個規模較小的子問題求解，而每一個子問題又可以分為幾個規模更小的子問題。基本上，所有的遞歸問題都可以用遞推公式來表示。

最重要的一點就是假設子問題已經解決了，現在要基於已經解決的子問題來解決當前問題；或者說，必須先解決子問題，再基於子問題來解決當前問題或者可以這么理解：遞歸解決的是有依賴順序關系的多個問題。

遞歸的優缺點：

優點：邏輯清楚，結構清晰，可讀性好，代碼簡潔，效率高（拓展：DFS深度優先搜素，前中後序二叉樹遍歷）

缺點：函數調用開銷大，空間復雜度高，有堆棧溢出的風險

Ⅱ 遞歸有什麼壞處

遞歸。要正推到已知條件，然後再從已經條件一步步返回。
如果量大的時候，太浪費存儲空間。
換句話也就是時間復雜度太大了。

Ⅲ 遞歸演算法的低效性

先回答問題。
內存方面，一般情況下遞歸的開銷比非遞歸大；
運行速度方面，一般情況下遞歸比非遞歸快；
代碼實現上，難度不一而論，要看具體問題上人腦解決和電腦解決的思路差異大小，一般而言，遞歸問題用非遞歸思路和普通問題用遞歸思路時代碼實現都將復雜化；
運行穩定性上，非遞歸明顯占優；
代碼量，永遠是遞歸最少；

單論遞歸演算法的低效性，一般指的是其內存開銷太大。其他的特性與非遞歸比沒有確定的結果，要試解決的問題而定。

這里有一篇非常之精闢的短文，想要深入了解遞歸可以看下。
http://hi..com/ninke/blog/item/e3e244a942b621fd1f17a25e.html

Ⅳ 遞歸程序和非遞歸程序的優缺點是什麼

遞歸代碼少，設計到遞推和回歸兩個過程，邏輯理解困難， 務必避免調用層次過多，和調用堆棧使用的棧內存過大，可能導致stack overflow
非遞歸就是正常寫法了，遞歸的都能改成非遞歸的
遞歸演算法必須寫的很精確，否則容易造成死循環

Ⅳ 遞歸的主要用途和好處是什麼精髓在哪兒

這里有:
遞歸 遞歸做為一種演算法在程序設計語言中廣泛應用.是指函數/過程/子程序在運行過程序中直接或間接調用自身而產生的重入現像.
程序調用自身的編程技巧稱為遞歸（ recursion）。
一個過程或函數在其定義或說明中又直接或間接調用自身的一種方法，它通常把一個大型復雜的問題層層轉化為一個與原問題相似的規模較小的問題來求解，遞歸策略只需少量的程序就可描述出解題過程所需要的多次重復計算，大大地減少了程序的代碼量。遞歸的能力在於用有限的語句來定義對象的無限集合。用遞歸思想寫出的程序往往十分簡潔易懂。
一般來說，遞歸需要有邊界條件、遞歸前進段和遞歸返回段。當邊界條件不滿足時，遞歸前進；當邊界條件滿足時，遞歸返回。
注意：
(1) 遞歸就是在過程或函數里調用自身;
(2) 在使用遞歸策略時，必須有一個明確的遞歸結束條件，稱為遞歸出口。
遞歸演算法一般用於解決三類問題：
(1)數據的定義是按遞歸定義的。(Fibonacci函數)
(2)問題解法按遞歸演算法實現。(回溯)
(3)數據的結構形式是按遞歸定義的。(樹的遍歷，圖的搜索)
遞歸的缺點：
遞歸演算法解題的運行效率較低。在遞歸調用的過程當中系統為每一層的返回點、局部量等開辟了棧來存儲。遞歸次數過多容易造成棧溢出等

Ⅵ 遞歸的通俗解釋是什麼

程序調用自身的編程技巧稱為遞歸（ recursion）。遞歸作為一種演算法在程序設計語言中廣泛應用。

一個過程或函數在其定義或說明中有直接或間接調用自身的一種方法，它通常把一個大型復雜的問題層層轉化為一個與原問題相似的規模較小的問題來求解，遞歸策略只需少量的程序就可描述出解題過程所需要的多次重復計算，大大地減少了程序的代碼量。

遞歸的能力在於用有限的語句來定義對象的無限集合。一般來說，遞歸需要有邊界條件、遞歸前進段和遞歸返回段。當邊界條件不滿足時，遞歸前進；當邊界條件滿足時，遞歸返回。

遞歸的缺點：

遞歸演算法解題相對常用的演算法如普通循環等，運行效率較低。因此，應該盡量避免使用遞歸，除非沒有更好的演算法或者某種特定情況，遞歸更為適合的時候。在遞歸調用的過程當中系統為每一層的返回點、局部量等開辟了棧來存儲。遞歸次數過多容易造成棧溢出等。

以上內容參考：網路-遞歸

Ⅶ 遞歸演算法有何特點

遞歸4—遞歸的弱點

之所以沒有把這段歸為演算法的討論，因為這里討論的不在是演算法，而只是討論一下濫用遞歸的不好的一面。

遞歸的用法似乎是很容易的，但是遞歸還是有她的致命弱點，那就是如果運用不恰當，濫用遞歸，程序的運行效率會非常的低，低到什麼程度，低到出乎你的想像！當然，平時的小程序是看不出什麼的，但是一旦在大項目里濫用遞歸，效率問題將引起程序的實用性的大大降低！

例子：求1到200的自然數的和。

第一種做法：

#include <stdio.h>

void main()

{

int i;

int sum=0;

for(i=1;i<=200;i++)

{

sum+=i;

}

printf("%d\n",sum);

}

該代碼中使用變數2個，計算200次。再看下個代碼：

#include <stdio.h>

int add(int i)

{

if(i==1)

{

return i;

}

else

{

return i+add(i-1);

}

}

void main()

{

int i;

int sum=0;

sum=add(200);

printf("%d\n",sum);

}

但看add（）函數，每次調用要聲明一個變數，每次調用要計算一次，所以應該是200個變數，200次計算，對比一下想想，如果程序要求遞歸次數非常多的時候，而且類似與這種情況，我們還能用遞歸去做嗎？這個時候寧願麻煩點去考慮其他辦法，也要嘗試擺脫遞歸的干擾。

21:21 | 添加評論 | 固定鏈接 | 引用通告 (0) | 記錄它 | 計算機與 Internet
程序演算法5—遞歸3—遞歸的再次挖掘

遞歸的魅力就在於遞歸的代碼，寫出來實在是太簡練了，而且能解決很多看起來似乎有規律但是又不是一下子能表達清楚的一些問題。思路清晰了，遞歸一寫出來問題立即就解決了，給人一重感覺，遞歸這么好用。我們在此再更深的挖掘一下遞歸的用法。

之前再強調一點，也許有人會問，你前邊的例子用遞歸似乎是更麻煩了。是，是麻煩了，因為為了方便理解，只能舉一些容易理解的例子，一般等實際應用遞歸的時候，遠遠不是這種狀態。

好了我們現在看一個數字的序列；有一組數的集合{1，2，4，7，11，16，22，29，37，46，56……}我故意多給幾項，一般是只給前4項讓你找規律的。序列給了，要求是求前50項的和。規律？有？還是沒有？一看就象有，但是又看不出來，我多給了幾項，應該很快看出來了，哦，原來每相鄰的兩項的差是個自然數排列，2-1=1，4-2=2，7-4=3，11-7=4，16-11=5……

好了，把規律找出來了，一開始可能覺得沒頭緒，沒問題，咱們把這個序列存放到一個數組總可以吧！那我們就聲明一個數組，存放前50個數據，一個一個相加總可以了。於是有了下邊的寫法：

#include <stdio.h>

void main()

{

int i,a[50],sum=0;

a[0]=1;

for(i=1;i<50;i++)

{

a[i]=a[i-1]+i;

}

for(i=0;i<50;i++)

{

sum+=a[i];

}

printf("%d\n",sum);

}

好了，代碼運行一下，結果出來了，正確不正確呢？自己測試吧，把50項改成1、2、3、4、5……項，試試前多少項是不是正確，雖然這不是正確的測試方法，但是的確是常用的測試方法。

等到這個代碼已經完全理解了，完全明白了正個計算過程，我們就應該對這段代碼進行改寫優化了，畢竟這個代碼還是不值得用一個數組的，那麼我們嘗試著只用變數去做一下：

#include <stdio.h>

void main()

{

int i;

int number=1;

int sum=0;

for(i=0;i<50;i++)

{

number+=i;

sum+=number;

}

printf("%d\n",sum);

}

不知道我這樣寫是不是跨度大了點，但是我不準備詳細解釋了，很多東西需要你去認真分析的，所以很多東西如果不懂，自己想清楚比別人解釋的效果會更好，因為別人講只能讓你理解，如果你自己去想，你就在理解的同時學會了思考。

這個代碼寫出來，不要繼續看下去，先自己嘗試著把這個題目用遞歸做一下看看自己能不能寫出來，當然，遞歸並不是那麼輕松就能使用的，有時候也是需要去細心設計的。如果做出來了，對比一下下邊的代碼，如果沒有寫出來，建議認真分析後邊的代碼，然後最好是能完全掌握，能自己隨時把這行代碼寫出來：

#include <stdio.h>

int add(int n,int num,int i)

{

num+=i;

if(i>=n-1)

{

return num;

}

else

{

return num+add(n,num,i+1);

}

}

void main()

{

int sum;

sum=add(50,1,0); /*50表示前50象項*/

printf("%d\n",sum);

}

當然這個代碼中的n只是一個參考變數，如果把if(i>=n-1)中的n該成50，那麼就不需要這個n了，函數兩個參數就可以了，這樣寫是為了修改方便。

20:28 | 添加評論 | 固定鏈接 | 引用通告 (0) | 記錄它 | 計算機與 Internet
程序演算法4—遞歸2—遞歸的魅力

兩天沒有再寫下去，因為畢竟有時候會有點心情問題，有時候覺得心情不好，一下子什麼東西都想不起來了，很多時候寫一些東西是需要狀態的，一旦狀態有了，想的東西才能順利的寫出來，雖然有些東西寫出來在別人看來很垃圾，但是起碼自己覺得還是相當滿意的，我寫這個本來就沒有多少技術含量，只是想給初學程序的人一些指引，加快他們對程序的領悟！

好了，言歸正傳，繼續上次遞歸的討論，看看遞歸的魅力所在。

有這樣一個問題，說一個猴子和一堆蘋果，猴子一天吃一半，然後再吃一個，10天後剩下一個了，也就是說吃了10次，剩下1個了。問原來一共有多少蘋果。

當然我們的目的不是求出蘋果的數量，而是尋求一種解決問題的方法，這個問題一出來，通常對程序掌握深度不一樣的朋友對這個題會有不同的認識，首先介紹一種解決方法，這種人腦袋還是比較聰明的，思路非常的明確，也有可能語言工具掌握的也不錯，代碼寫出來非常准確，先看一下代碼再做評價吧：

#include <stdio.h>

void main()

{

int day=10;

int apple;

int i,j;

for(i=1;;i++)

{

apple=i;

for(j=0;j<day;j++)

{

if(apple%2==0&&apple>0)

{

apple/=2;

apple--;

}

else

{

break;

}

}

if(j==day&&apple==1)

{

printf("%d\n",i);

return;

}

}

}

程序的大概思路很明確，簡單介紹一下，這種寫法就是從一個蘋果開始算起，for(i=1;;i++)的作用就是改變蘋果的數量，如果1個符合條件，那就試試2個，然後3個、4個一直到適合為止，里邊的for循環就是把每一次取得的蘋果的數目進行計算，如果每次都能順利的被2整除（也就是說每次都能保證猴子能正好吃一半），然後再減一一直到最後，如果最後蘋果剩下是一個而且天數正好是10天，那麼就輸出一下蘋果的數目，整個程序退出，如果看不明白的沒關系，這個寫法非常的不適用，我們叫寫出這種演算法的人傻X，雖然這種人腦袋也挺聰明，能寫出一些新鮮的寫法，但是又臟又臭，代碼既不簡練又不高效。

所以說，有時候有些人以為自己學的很好了，自己所做的一切都是最好的，這種想法是不正確的，也許有些初學者沒有什麼經驗寫出來的代碼卻更讓人容易明白點，那麼也是先看看代碼：

#include <stdio.h>

void main()

{

int day[11];

int i;

day[0]=1;

for(i=1;i<11;i++)

{

day[i]=(day[i-1]+1)*2;

}

printf("%d\n",day[10]);

}

代碼不長，而且也恰當的應用了題目中的規律，不是說要吃一半然後再吃一個嗎？那我用數組來存放每天蘋果的數量，用day[0]表示最後一天的蘋果數量，那就是剩下的一個，然後就是找規律了，什麼規律？就是如果猴子不多吃一個的話，那就是正好吃了一半，也就是說猴子當天吃了之後剩餘的蘋果的數目加1個然後再乘以2就是前一天的數目了，這樣一想這個題目就簡單的多了，於是這個題用數組就輕松的做出來了。

那麼這個代碼究竟是不是已經很好了呢，我們注意到，這里邊每個數組元素只用了一次並沒有被重復使用，再這種情況下我們是不是可以用一種方法代替數組呢？於是就有了更優化的寫法，這個寫法似乎已經是相當簡練了：

#include <stdio.h>

void main()

{

int apple=1;

int i;

for(i=0;i<10;i++)

{

apple=(apple+1)*2;

}

printf("%d\n",apple);

}

代碼寫到這里已經把問題完全抽象化了，所以我們就應該站在數學的角度去分析了。也許我們就應該結束了討論，但是偏偏這個時候，又來了遞歸，悄悄的通過美麗的調用顯示了一下她的魅力：

#include <stdio.h>

int apple(int i)

{

if(i==0)

{

return 1;

}

else

{

return (apple(i-1)+1)*2;

}

}

void main()

{

int i;

i=apple(10);

printf("%d\n",i);

}

原理都還是一樣的，但是寫出來的格式已經完全變掉了，沒有了for循環。假想一個復雜的問題遠比這個問題復雜，而且沒有固定循環次數，那麼我們再使用循環雖然也能解決問題，但是可能面臨循環難以設計、控制等問題，這個時候用遞歸可能就會讓問題變的非常的清晰。

另外說一點，一般我這里的代碼，並不是從最差到最好的，基本排列是從最差到最合適的代碼（當然是本人認為最合適的，也許還有更好的，本人能力所限了），然後最後給出一種比較違反常規的代碼，一般是不贊成用最後一種代碼的，當然有時候最後一種代碼也許是最好的選擇，看情況吧！

20:25 | 添加評論 | 固定鏈接 | 引用通告 (0) | 記錄它 | 計算機與 Internet
10月15日
程序演算法3—遞歸1—遞歸小顯威力

現在用C語言實現一個字元串的倒序輸出，當然，方法也是很多的，但是如果程序中能有相對優化的方法或者簡單明了易讀的方法，那對你自己或者別人都是一種幸福。

第一種寫法，這類寫法既浪費內存又不實用，一般是剛學程序的才這樣做，程序的結構很簡單，利用的是數組：

#include <stdio.h>

void main()

{

char c[2000];

int i,length=0;

for(i=0;i<2000;i++)

{

scanf("%c",&c[i]);

if(c[i]=='\n')

{

break;

}

else

{

length++;

}

}

for(i=length;i>0;i--)

{

printf("%c",c[i-1]);

}

printf("\n");

}

這段代碼中的數組，聲明大了浪費內存空間，聲明小了又怕不夠，所以寫這種代碼的人一般寫完之後會祈禱，祈禱測試的人不要輸入的太多，太多就不能完全顯示了！

與其這么提心吊膽，於是又有人想出了第二種方法，終於解決了一些問題，而且完全實現了程序的實際要求，於是，這種人經過一番苦想，覺得問題終於可以解決了，這種方法看起來是一種很不錯的方法。

#include <stdio.h>

#include <malloc.h>

void main()

{

int i;

char *c;

c=(char *)malloc(1*sizeof(char));

for(i=0;;i++)

{

*(c+i)=getchar();

if(*(c+i)=='\n')

{

*(c+i)='\0';

break;

}

else

c=(char *)realloc(c,(i+2)*sizeof(char));

}

for(--i;i>=0;i--)

{

putchar(*(c+i));

}

printf("\n");

free(c);

}

怎麼樣？不錯，准確的應用內存，幾乎沒有浪費什麼空間，這種方法也體現了一下指針的強大功能，寫這個程序雖然不敢說這個人已經掌握了指針的應用，但是起碼可以說他已經會用指針了。代碼寫出來，看起來已經有點美感。

但是也有一些人還是比較喜歡動腦筋的，經過一番思考，終於想出了第三種比較容易寫的方法，也許有寫初學者可能覺得有些難度，但是事實上這個東西一點都不難，如果稍微有點程序功底之後再看這段代碼，應該是相當輕松！

#include <stdio.h>

void run()

{

char c;

c=getchar();

if(c!='\n')

{

run();

}

else

{

return;

}

putchar(c);

}

void main()

{

run();

printf("\n");

}

寫出的代碼讓人眼前一亮，哇！原來遞歸功能簡單而又好用，那我們為什麼不好好利用呢？但是遞歸也不一定就是最好的選擇，因為有時候雖然遞歸用起來很方便，但是效率卻不高，以後的討論中還會詳細說明。

Ⅷ 在c語言中遞歸和迭代有什麼區別和聯系各自的優缺點是什麼二者分別適合解決什

能力有限，僅知幾點
兩者都是重復某一操作直到滿足條件為止。
不同之處在於，遞歸是函數調用自身，而迭代是使用循環。
某些情況下遞歸更加簡單，可讀性更高，而用循環則十分復雜。如二分法，快速排序等。
遞歸很容易導致棧溢出，導致程序崩潰，而循環不會。
綜上所述，能用循環用循環，遞歸是萬不得已的手段。

Ⅸ C語言遞歸有什麼用處，又有什麼缺點

遞歸好處：代碼更簡潔清晰，可讀性更好
遞歸可讀性好這一點，對於初學者可能會反對。實際上遞歸的代碼更清晰，但是從學習的角度要理解遞歸真正發生的什麼，是如何調用的，調用層次和路線，調用堆棧中保存了什麼，可能是不容易。但是不可否認遞歸的代碼更簡潔。一般來說，一個人可能很容易的寫出前中後序的二叉樹遍歷的遞歸演算法，要寫出相應的非遞歸演算法就比較考驗水平了，恐怕至少一半的人搞不定。所以說遞歸代碼更簡潔明了。

遞歸壞處：由於遞歸需要系統堆棧，所以空間消耗要比非遞歸代碼要大很多。而且，如果遞歸深度太大，可能系統撐不住。