跳到主要内容
CalcMax

斐波那契计算器

范围:2 – 78

结果

1, 1, 2, 3, 5, 8, 13, 21, 34, 55

各项(F(1) 到 F(n))

第 n 项
55
黄金比近似值
1.61764706

斐波那契数列以两个 1 开头,此后的每一项都是它前面两项之和:1、1、2、3、5、8、13、21、34、55,如此下去。这一页给出前 n 项、单独给出第 n 项的值,以及最后一项与它前一项之比。最后那个输出才是这一页比一张对照表更值钱的原因。比值起初是摇摆的——2、接着 1.5、接着 1.6667、接着 1.6——然后很快收敛到一个数上:1.6180339887…,也就是黄金比。到第二十项,这个比值已经准到百万分之一以内。定义里没有任何地方提到那个数;它是从加法里掉出来的,而看着它掉出来才是有意思的部分。这一页从 1 开始数,所以 F(1) 是 1、F(2) 是 1、F(3) 是 2、F(10) 是 55。通行的还有另一种从 F(0) = 0 开始的约定,在它下面 F(5) 是 5,而这一页给出的是 8。两种都没错,但一页必须选一种,而把两种混起来是斐波那契答案出错最常见的方式。78 项这个上界不是想法的限制,而是算术的限制:各项在 F(79) 处越过了双精度能精确表示的范围,所以这一页停在答案开始变成近似值的前一项。这个数列本身值得说一句,因为它是少见的、能从两个方向抵达的例子。一个方向是一道关于兔子繁殖的题:一开始有一对,每对要一个月长成熟,此后每个月生一对新的,每个月初的对数恰好就是这些数。另一个方向就是上面的定义——把最后两项相加——而这两件事是同一件事并不显然,这也是这个数列会出现在彼此毫无关系的地方的原因。向日葵种子的螺旋、松果的鳞片、叶子绕茎的排列都跑在这些数上,而原因始终是比值所收敛到的那个黄金比。这个数列不是自然界的定律,也不是什么设计原则:它是一个递推,恰好逼近那个最难用分数逼近的数,而自然界用到它的地方,正是这个逼近划得来的地方。

前十项,以及每一项与它前一项之比

n该项与前一项之比
11—
211.00000000
322.00000000
431.50000000
551.66666667
681.60000000
7131.62500000
8211.61538462
9341.61904762
10551.61764706

把最右边那一列从上往下读,你看到的是一个数在拿定主意。它从 2 开始——第二项是 1、第一项是 1,但 2 ÷ 1 是 2——然后掉到 1.5,又弹回 2,再落到 1.667,此后摆动迅速变小:1.6、1.625、1.615、1.619、1.617647。这种来回摆动才是重点。比值不是从一侧靠近 1.618 的;它一会儿过、一会儿欠,交替进行,而每次摆动的幅度大约只有上一次的一半,这就是到第十行时印出来的值已经在两位小数上正确的原因。真正的黄金比从 1.6180339887 开始,所以到第十行,剩下的误差在第三位小数上。第一行没有比值而是一个破折号,因为没有前一项可除——这与这一页拒绝只算一项是同一个理由。

公式

F(1) = 1,F(2) = 1,F(n) = F(n − 1) + F(n − 2) ⇒ 1、1、2、3、5、8、13、21、34、55……;相邻两项之比 → φ = (1 + √5) / 2 = 1.6180339887…

F(1) = F(2) = 1
两个起始值,也是这一页明确表态的那个选择。从 1 开始数意味着 F(1) 与 F(2) 都是 1,F(10) 是 55。另一种常见约定设 F(0) = 0、F(1) = 1,它把每个下标挪一位,于是 F(5) 是 5 而不是 8。两种都不错,但它们在每一个下标上都对不上
F(n) = F(n − 1) + F(n − 2)
递推式,也就是全部定义。每一项是它前面两项之和:1 + 1 = 2,1 + 2 = 3,2 + 3 = 5,3 + 5 = 8。从两个起始值往前推,正是这一页能像给出十项一样轻松给出上千项的原因——没有公式要解,只有一次重复的加法
n
你要多少项,从 2 到 78。下界是 2 而不是 1,因为比值输出需要一项与它前面那一项,只要一项就没有东西可除;这一页拒绝它,而不是印一个空的比值。上界是各项在普通浮点算术里不再精确的那个位置
F(78) = 8944394323791464
这一页能走到的最后一项,也是它停在这里的原因。F(79) 是 14472334024676221,已经超出双精度能精确表示的最大整数 9007199254740991——从那里起印出来的数字就是近似值而不是数列本身。这一页拒绝 79,而不是印一个几乎正确的项
F(n) / F(n − 1)
比值输出。它不是黄金比,这一页也没有说它是:第五项给出的 1.6667 离 1.618 还远。它是个估计值,而且改进得很快——第二十项已经准到这一页印的八位小数
φ = 1.6180339887…
黄金比,这些比值所收敛到的那个数。它是 x² = x + 1 的正根,而那条方程就是把同一个递推写成等式的样子——这不是巧合,正是斐波那契比值落在它身上的原因。注意印出来的估计值最多到 1.61803399:这一页只显示八位小数,真值还在后面

查一项是最朴素的用法:一道题问第十个斐波那契数,或者课本里的数列走得比你愿意手算的更远,这一页给出那个值以及通向它的整串项。比值输出服务的是另一个问题——黄金比是从哪来的。看着 2、1.5、1.6667、1.6、1.625、1.615 一路向 1.618 收拢,比读一遍证明要短得多,而这一页的参考表就是为这种读法排的。第三种用处在编程与课业里,这个递推是讲递归时的标准第一个例子,而它同时也是「递归定义但用迭代算便宜得多」的标准例子——这一页的循环就是迭代版,这也是 78 项不花任何代价的原因。这些数还出现在一切自我叠加的计数问题里:用正方形与长方形铺一条带子的铺法数、上楼梯每次走一级或两级的走法数、每个季节分一次叉的植物的分叉数,都遵循同一个递推。当问题在于那个比值而不在于数列时,golden-ratio-calculator 把它当成一个有自己性质的数来对待;当问题在于增长模式时,exponential-growth-calculator 覆盖的是这些项按步逼近的那条光滑曲线。

算例

  1. 前十项:1、1、2、3、5、8、13、21、34、55

    1. 从这一页使用的两个起始值 1 与 1 开始
    2. 1 + 1 = 2,接着 1 + 2 = 3,接着 2 + 3 = 5,接着 3 + 5 = 8
    3. 继续:5 + 8 = 13,8 + 13 = 21,13 + 21 = 34,21 + 34 = 55
    4. 十项,所以第十项是 55;最后两项之比是 55 ÷ 34 = 1.61764706

    这一页的默认输入。注意第十项是 55,而 55 与 34 之比是 1.61764706——接近黄金比,但在第三位小数上仍看得出偏差。这正是这个数列值得盯着看而不是查一下的原因:收敛很快,但不是瞬间的,而十项还不够让印出来的八位小数走到 1.61803399。

  2. 最短的一串:两项

    1. 两项是这一页接受的最小请求
    2. 数列就只是那两个起始值:1 与 1
    3. 第二项是 1,所以第 n 项那个输出是 1
    4. 比值是 1 ÷ 1 = 1——这是这一页能给出的、离黄金比最远的比

    下界,也是它为什么是 2 而不是 1 的原因。比值输出至少要两项才存在;只有一项就没有东西可除,所以这一页拒绝 1,而不是印一个空白或者一个零。比值 1 也是整段收敛的起点:此后每一个比值都是从它出发走的一步,而 1 到 1.618 的这一段路,正是下面那张表一项一项铺开的。

  3. 比值落定的地方:二十项

    1. 从第十项继续递推:34 + 55 = 89,55 + 89 = 144,如此下去
    2. 第二十项是 6765,第十九项是 4181
    3. 6765 ÷ 4181 = 1.61803396317…
    4. 按这一页印的八位小数四舍五入,是 1.61803396

    二十项就够了。真正的黄金比从 1.6180339887 开始,而这里的估计值与它在前七位小数上一致——偏差已经落到第八位上,也就是印出来的最后一位。拿它跟十项那一档比:那里误差在第三位小数上就已经看得见。这正是这一页存在的意义:递推的定义里与黄金比毫无关系,而它却把黄金比产了出来,很快,而且只靠加法。

局限

项数必须是 2 到 78 之间的整数。1 是拒绝的,因为比值输出需要两项才存在;79 也是拒绝的,因为各项从那里起不再精确:F(78) 是 8944394323791464,是双精度值能精确装下的最后一个斐波那契数,而 F(79) 越过了 9007199254740991 这条线。这一页拒绝这个请求,而不是返回一个近似的项——因为一个几乎正确、却印成十六位数字的数,看起来与一个正确的数一模一样。计数从 1 开始,这一页用的是 F(1) = F(2) = 1。另一种流传很广的约定设 F(0) = 0、F(1) = 1,它把每一个下标挪一位——在那种约定下第五项是 5,而这里是 8。两种约定都见于教材与软件,所以如果你拿这一页与另一个来源对照、发现数值整整错开一位,那是这个原因而不是算错。比值输出是估计值,印到八位小数;任何有限项数下它都不精确等于黄金比,尽管到第七十八项时印出来的值与黄金比在这八位上是同一个数。各项本身印成逗号分隔的一行,不用千分位,所以第十项读作 55,第七十八项读作 8944394323791464——要念长项请用第 n 项那个输出,而不是这一行。最后,参考表固定是前十项、不跟着你的输入变;它在那儿是为了展示比值怎么落定,不是回答你输入了什么。

常见问题

数列是从 F(0) 开始还是从 F(1) 开始?
这一页从 F(1) 开始,所以 F(1) = 1、F(2) = 1、F(3) = 2,第十项是 55。另一种流传很广的约定设 F(0) = 0、F(1) = 1,它把每个下标挪一位——在它下面第五项是 5,而这里是 8。两种都见于教材与软件,也都不是错误。但如果你拿这一页和另一个来源对照,发现数值整整错开一位,原因就在这里;这是斐波那契答案出错最常见的方式。
为什么比值一直在变,不是一下子就定下来?
因为它是一个极限而不是一个恒等式。每一项是前两项之和,于是相邻两项之比自己也有一个固定的变化规则,而它每一次都过一点或欠一点,摆动的幅度大约只有上一次的一半。这一页的表把这件事摆出来了:2、1.5、2、1.667、1.6、1.625,然后收窄到 1.615 与 1.619。十项已经接近,二十项足够走到这一页印的八位小数,而任何有限项数都不会精确等于黄金比——只会更接近它。
黄金比是什么,这个数列为什么会产出它?
黄金比是 1.6180339887…,是 x² = x + 1 的正根。那条方程就是斐波那契递推换一种写法——如果比值真的落在某个数上,那个数就必须满足它——这就是数列会落在它身上、而这件事既不是巧合也不是趣闻的原因。它同时也是最难用分数逼近的数,因为它的连分数全是 1,而植物按它来安排叶片与种子的间距,用到的正是这条性质。
为什么最多只能要 78 项?
因为 F(79) 已经大于双精度值能精确表示的最大整数 9007199254740991。F(78) 是 8944394323791464,是精确的;F(79) 是 14472334024676221,存起来会是接近它的另一个数。这一页拒绝这个请求而不是印一个近似值,因为一个印成十六位数字的项看起来与正确的项一模一样——从输出上根本看不出误差。项数的上限是个浮点事实,不是数学事实;数列本身是无限的。
兔子问题是怎么扯进来的?
斐波那契是用一道题引出这个数列的:一开始有一对兔子,每对要一个月长成熟,此后每个月生一对新的,数每个月初有多少对。数出来就是 1、1、2、3、5、8……因为上个月成熟的对都还在,而这个月新生的对来自一个月前成熟的那批——这就是那个递推,从完全另一个方向抵达了它。值得知道,是因为它说明这个数列不是由某一个应用定义的。
能不能不列前面的项,直接算出第 n 项?
原理上可以,这一页的第 n 项输出也确实单独给你那个数,但它是同一趟循环产出来的,不是走捷径公式。原因在精确性:确实有个通项公式——比内公式——用黄金比直接给出第 n 个斐波那契数,但它涉及无理数的幂,在浮点算术里随着 n 变大会离真正的整数越来越远。加整数是精确的,那个公式不是,所以这一页选择做加法。从两个起始值往前推也是 78 项不花代价的原因——没有公式要解,只有一次重复了 76 遍的加法。

参考资料

相关计算器