利用递归、迭代解决斐波那契数列问题与汉诺塔难题

有人说，“普通程序员使用迭代，天才程序员使用递归“，真是这样吗？

1.浅谈递归与迭代

<1>递归的基本概念: 程序调用自身的编程技巧称为递归,是函数自己调用自己。

一个函数在其定义中直接或间接调用自身的一种方法,它通常把一个大型的复杂的问题转化为一个与原问题相似的规模较小的问题来解决,可以极大的减少代码量.递归的能力在于用有限的语句来定义对象的无限集合.

• 使用递归要注意的有两点:

  1)递归就是在过程或函数里面调用自身;

  2)在使用递归时,必须有一个明确的递归结束条件,称为递归出口.

• 递归分为两个阶段:

  1)递推:把复杂的问题的求解推到比原问题简单一些的问题的求解;

  2)回归:当获得最简单的情况后,逐步返回,依次得到复杂的解.

利用递归可以解决很多问题:如背包问题,汉诺塔问题,斐波那契数列…等.

由于递归引起一系列的函数调用,并且有可能会有一系列的重复计算,递归算法的执行效率相对较低。

<2>迭代:利用变量的原值推算出变量的一个新值.如果递归是自己调用自己的话,迭代就是A不停的调用B。

2.斐波那契数列的递归与迭代解决方案

问题描述：斐波那契数列又称兔子序列

话说有一个意大利数学家——斐波那契提出过这样一个问题：在第一个月有一对刚出生的小兔子，在第二个月小兔子变成大兔子并开始怀孕，第三个月大兔子会生下一对小兔子，并且以后每个月都会生下一对小兔子。 如果每对兔子都经历这样的出生、成熟、生育的过程，并且兔子永远不死（神了），那么兔子的总数是如何变化的？

大概兔子们的族谱是这样的：

第一个月只有一对兔宝宝，1对兔子。

第二个月兔宝宝变成大兔子，1对兔子。

第三个月大兔子生了一对兔宝宝，一大一小2对兔子。

第四个月大兔子继续生一对兔宝宝，小兔子变成大兔子。两大一小3对兔子。

……

就会有这样一个数列列表：

这个数列的重要意义在于它与黄金分割比关系密切，这个数列中越往后，相邻的两个数（上图中的兔子总数）之比越接近黄金分割比；因此我们在算法中常用斐波那契数列来代替黄金分割比。

当我们知道数列中两个相邻的数，不难求出下一个数： n = (n-1)+(n -2)，那么利用程序怎么实现呢？

迭代方法程序如下：

递归方法程序如下：

通过的上图我们可以发现，使用递归方法的代码量少于迭代，那么问题来了，递归一定比迭代好吗？

我们讲上述两种方法的输入改为40，感受一下结果：

你可以明显感觉到，假如递归使用不当，代码的运行效率会很低（当然我的电脑配置低也是影响因素之一，但是递归的问题肯定是客观存在的）

3.递归的分治思想——汉诺塔难题解决方案的实现

问题描述：

相传在古印度圣庙中，有一种被称为汉诺塔(Hanoi)的游戏。该游戏是在一块铜板装置上，有三根杆(编号A、B、C)，在A杆自下而上、由大到小按顺序放置64个金盘(如下图)。游戏的目标：把A杆上的金盘全部移到C杆上，并仍保持原有顺序叠好。操作规则：每次只能移动一个盘子，并且在移动过程中三根杆上都始终保持大盘在下，小盘在上，操作过程中盘子可以置于A、B、C任一杆上。

问题分析：

一股脑地考虑每一步如何移动很困难，我们可以换个思路。先假设除最下面的盘子之外，我们已经成功地将上面的63个盘子移到了b柱，此时只要将最下面的盘子由a移动到c即可。如图：

当最大的盘子由a移到c后，b上是余下的63个盘子，a为空。因此现在的目标就变成了将这63个盘子由b移到c。这个问题和原来的问题完全一样，只是由a柱换为了b柱，规模由64变为了63。因此可以采用相同的方法，先将上面的62个盘子由b移到a，再将最下面的盘子移到c……对照下面的过程，试着是否能找到规律：

• 1.将b柱子作为辅助，把a上的63个圆盘移动到b上
• 2.将a上最后一个圆盘移动到c
• 3.将a作为辅助，把b上的62个圆盘移动到a上
• 4.将b上的最后一个圆盘移动到c
  …

也许你已经发现规律了，即每次都是先将其他圆盘移动到辅助柱子上，并将最底下的圆盘移到c柱子上，然后再把原先的柱子作为辅助柱子，并重复此过程。

这个过程称为递归，即定义一组基本操作，这组操作将规模小一点（或大一点）的操作当做一个整体——无需关心它的细节，只当它已经完成了——然后执行剩下的操作。而在更小或更大的规模中也依此操作，直到规模达到预定值。

这个问题使用迭代来解决超级难，或者说不是我这个级别能够理解的 😦😦😦😦

代码如下：

上述代码相当于一个游戏攻略，当你输入汉诺塔的层数（如：3），它会告诉你每一步该怎么走：（有兴趣可以试试，步骤不对，我用自己祭旗 😃😃😃😃 ）

4.辩证看递归和迭代

所谓递归，简而言之就是应用程序自身调用自身，以实现层次数据结构的查询和访问。递归的使用可以使代码更简洁清晰，可读性更好（对于初学者到不见得），但由于递归需要系统堆栈，所以空间消耗要比非递归代码要大很多，而且，如果递归深度太大，可能系统资源会不够用。

往往有这样的观点：能不用递归就不用递归，递归都可以用迭代来代替。

诚然，在理论上，递归和迭代在时间复杂度方面是等价的（在不考虑函数调用开销和函数调用产生的堆栈开销），但实际上递归确实效率比迭代低，既然这样，递归没有任何优势，那么是不是就，没有使用递归的必要了，那递归的存在有何意义呢？ 万物的存在是需要时间的检验的，递归没有被历史所埋没，即有存在的理由。从理论上说，所有的递归函数都可以转换为迭代函数，反之亦然，然而代价通常都是比较高的。但从算法结构来说，递归声明的结构并不总能够转换为迭代结构，原因在于结构的引申本身属于递归的概念，用迭代的方法在设计初期根本无法实现，这就像动多态的东西并不总是可以用静多态的方法实现一样。这也是为什么在结构设计时，通常采用递归的方式而不是采用迭代的方式的原因，一个极典型的例子类似于链表，使用递归定义及其简单，但对于内存定义(数组方式)其定义及调用处理说明就变得很晦涩，尤其是在遇到环链、图、网格等问题时，使用迭代方式从描述到实现上都变得不现实。因而可以从实际上说，所有的迭代可以转换为递归，但递归不一定可以转换为迭代。

采用递归算法需要的前提条件是，当且仅当一个存在预期的收敛时，才可采用递归算法，否则，就不能使用递归算法。

递归其实是方便了程序员难为了机器，递归可以通过数学公式很方便的转换为程序。其优点就是易理解，容易编程。但递归是用栈机制实现的，每深入一层，都要占去一块栈数据区域，对嵌套层数深的一些算法，递归会力不从心，空间上会以内存崩溃而告终，而且递归也带来了大量的函数调用，这也有许多额外的时间开销。所以在深度大时，它的时空性就不好了。

而迭代虽然效率高，运行时间只因循环次数增加而增加，没什么额外开销，空间上也没有什么增加，但缺点就是不容易理解，编写复杂问题时困难。

因而，“能不用递归就不用递归，递归都可以用迭代来代替”这样的理解，还是辩证的来看待，不可一棍子打死。