最近在做网站测试时，遇到了需要在输入框输入 3000 字的测试用例。联想到平时聊天时经常复制粘贴一堆笑脸刷屏讨 MM 欢心的行为，不由想到了一个有趣的问题：为了输入一定数量的字符，最少需要按多少个键？

     大家最常用的策略或许是， 先输一些字符，然后全选复制，粘贴到一定规模后，再全选复制，粘贴到一个新的数量级，如此反复。注意到进入全选状态（并且复制后），第一次粘贴将会覆盖掉选中的部分，第二次粘贴才会增加原来的文本长度。当然，全选复制后按一次向右键也可以消除选中状态，不过却并没有节省按键次数。因此我们规定，在输入字符时只有四种原子操作：

    1. 按一个按键，输入一个字符

    2. 按 Ctrl + A ，全选

    3. 按 Ctrl + C ，复制

    4. 按 Ctrl + V ，粘贴

     排除明显不划算的行为，真正的决策其实只有两种：

    1. 按一次按键，输入一个字符

    2. 按 k + 2 次按键，将现有内容复制成 k 份。

     这样一来，我们就有了一个清晰的递推思路。设 f(n) 表示输入 n 个字符所需要的最少按键次数，则 f(n) 将会在 f(n-1) + 1 和 f(n/k) + k + 2 中取一个最小值（其中 k 取遍 n 的所有约数）。

     Mathematica 牛 B 就牛 B 在，这样的动态规划程序只需要一行便能写完：

     可见，输入 100 个字符需要 18 次按键。具体方法是，用 5 次按键输入 5 个字符，再用 7 次按键把它变成 25 个字符，再用 6 次按键把它变成 100 个字符。

     有趣的是，这个函数并不是单调的。输入 99 个字符需要的按键次数比输入 100 个字符需要的按键次数更多一些，事实上这最少要花费 20 次按键。方法是，先用 5 次按键输入 5 个字符，4 次按键把它变成 10 个字符，单独按一次键添加一个字符， 5 次按键把字符数复制粘贴到 33 ，再来 5 次按键把字符数复制粘贴到 99 。

     下面这个图是输入不同的字符数所需要的最少按键。

     可以看到， 20 次按键足以应付 100 以内任何数量的字符，也就是说 99 个字符所需要的按键次数已经是 100 个字符以内的情况中最大的了。不过，最悲剧的应该要数 83 个字符了，它是所有至少要用 20 次按键的情况中字符个数最少的（也即首次出现的要用 20 次按键才能输入的情况）。对应的输入方案是 5 → 20 → 80 → 81 → 82 → 83 （直到分析到这里，我才意识到，在考虑输入指定数量的字符时，引入退格键可以带来的更少的按键次数）。

     那么， 20 次按键最多可以输入多少个字符呢？为了解决这个问题，我们可以给出另外一个递推式。令 g(n) 为 n 次按键最多可以输入的字符个数。对于每一个 n ，考虑两种转移决策：要么在 n - 1 次按键能够达到的最大字符数基础上加 1 ，要么把 n - k 次按键能够达到的字符数复制成 k - 2 份。也就是说， g(n) 就等于 g(n-1) + 1 和 g(n-k) * (k-2) 的最大值，其中 k 可以从 3 取到 n - 1。我们还是用一句话写下这个转移方程式：

     可以看到， 20 次按键足以输入 150 个字符（方案是 6 → 30 → 150 ）， 30 次按键足以输入 1600 个字符（方案是 5 → 25 → 100 → 400 → 1600 ）。这样看上去，我们好像有了快速刷屏的指导思想：粘贴到原来的 4 倍长或者 5 倍长后再进行下一波全选复制粘贴似乎总是最优的选择。另外，这个数列增长得很快， 80 次按键能输入的字符数就已经上亿了。看来，要想刷屏到系统崩溃并不难，不足 100 次按键就能产生上 G 的数据。

     似乎这个增长速度是指数级的。描出 g(n) 的图象证实了我们这一想法：

     我们自然而然地想到观察数列 g(n) 相邻两项的比值：

     容易看到，当 n 到了一定大时，数列已经呈现出了一定的规律，多数时候都是以 1.25 倍的速度增长。给出并证明数列的通项公式或许会是一件非常有趣的事情。

建议继续学习：

1. 为什么Fibonacci数列相邻两项之比会趋于0.618？    (阅读：4431)
2. 千万不要迷信规律：大反例合集    (阅读：3782)
3. Fibonacci数列性质的组合证明    (阅读：3116)
4. 数学冷知识：不断取英文表达的字符数，最后总会得到数字4    (阅读：2597)
5. Hofstadter的非线性递推数列    (阅读：2033)