字符串 hello 当中连续出现了两个 l 。字符串 prototype 当中连续出现了两个 ot 。字符串 nonsense 当中连续出现了两个 nse 。如果某个字符串中连续出现了两个相同的片段，换句话说这个字符串里面含有形如 XX 的模式（其中 X 代表一个子串），我们就说这个字符串中含有一个“平方”（square）。如果某个字符串中没有平方出现，我们就说这个字符串是“免平方”的（square-free）。
如果只使用两种字符，比方说字符 0 和字符 1 的话，我们只能构造出一些长度非常有限的免平方字符串。事实上，我们只能构造出以下 6 个免平方字符串： 0 、 1 、 01 、 10 、 010 、 101 。然而，如果允许使用三种字符，比方说字符 0 、 1 、 2 的话，我们不但能够构造出任意长的免平方字符串，还能构造出无限长的免平方字符串。在继续阅读下去之前，你不妨先自己试试看。
下面是 2013 年 9 月 IBM Ponder This 的谜题。
A 和 B 在赌场玩一个游戏，他们要协同作战与庄家对抗。游戏一轮一轮地进行，每一轮的规则都是一样的：首先 A 赌 0 和 1 当中的某个数字，然后 B 再赌 0 和 1 当中的某个数字，最后庄家给出 0 和 1 当中的某个数字；如果所有的三个数字都相同，则 A 和 B 获胜，否则庄家获胜。游戏前， A 和 B 可以商量一个对策，但游戏一旦开始，除了下赌注本身之外，两人不能再有其他任何形式的交流了。
容易看出，如果 A 和 B 都随机下注，他们只有 25% 的获胜概率。然而，如果两人事先约定，在每一轮中， B 总是跟着 A 下注， A 赌什么 B 就赌什么，那么他们获胜的概率就会提高到 50% 。但是，不管采用哪种方案，在最坏情况下，两人都有可能一次也不能获胜。
有意思的事情出现了。在游戏开始前两人商量策略的时候，两人突然意识到， B 有办法偷到庄家将会在游戏中使用的 01 序列。也就是说，游戏开始后，每一轮里庄家要出什么， B 都将会知道。但是，一旦 B 拿到了这个 01 序列， B 就不能和 A 交流了。在这样的条件下，两人能做得比刚才更好吗？能！比如说，两人可以保证在最坏情况下也有至少 50% 的获胜次数： B 可以在第 1, 3, 5, 7, … 轮游戏中赌下一轮庄家将会出的那个数（这相当于暗示了 A 下一轮赌什么），两人便能保证在第 2, 4, 6, 8, … 轮游戏中获胜了。
我们的问题是：假设游戏一共有 9 轮，设计一种策略使得 A 和 B 能够保证至少 6 次胜利。
在早期的小型图像编辑软件中，考虑到时间空间的限制，再加上算法本身的难度，很多看似非常简单的功能都无法实现。比如说，很多图像编辑软件只允许用户把所选的内容旋转 90 度、 180 度或者 270 度，不支持任意度数的旋转。毕竟，如果我们只是旋转 90 度的整数倍，那么所有像素仅仅是在做某些有规律的轮换，这甚至不需要额外的内存空间就能完成。但是，如果旋转别的度数，那么在采样和反锯齿等方面都将会有不小的挑战。
不过， Windows 自带的画图软件聪明地用 skew 功能（中文版翻译成“扭曲”）部分地填补了无法自由变形的缺陷。随便选中图中的一块区域，再在菜单栏上选择“图像”→“拉伸/扭曲”，然后在“水平扭曲”那儿填写一个 -89 到 89 之间的整数（表示一个角度值），再按一下确定，于是整个图形就会像下图所示的那样被拉斜，其中 θ 就是你刚才填的度数。如果你填入的 θ 是负数值，则倾斜的方向会与下图方向相反。类似地，“垂直扭曲”功能会在竖直方向上对图形进行拉扯，如果角度值为正数，则整个图形会变得左低右高，如果角度值为负数，则整个图形会变得左高右低。
不过，这玩意儿对于我们来说似乎完全没用。估计 99% 的人在使用画图软件的时候就从来没用过这个功能吧。如果真是这样，那么今天的问题恐怕将会是大家最近一段时间见过的最有趣的问题了：想办法利用 Windows 画图中的扭曲功能（近似地）实现 28 度旋转。
还记得小时候有一道经典奥数题，大概是让你把两个数字 1 、两个数字 2 、两个数字 3 和两个数字 4 排成一个 8 位数，使得其中两个数字 1 之间正好夹着 1 个数字，两个数字 2 之间正好夹着 2 个数字，两个数字 3 之间正好夹着 3 个数字，两个数字 4 之间正好夹着 4 个数字。稍作尝试便可得出正确答案： 4, 1, 3, 1, 2, 4, 3, 2 。如果把逆序后的数列视作本质相同的数列，那么上面这个答案是唯一的。这个问题是由 C. Dudley Langford 在 1958 年提出的，因此我们把它叫做 Langford 数列。
当 n = 3 时， Langford 数列也是唯一的： 2, 3, 1, 2, 1, 3 。我小时候曾经没日没夜地试图寻找 n = 5 时的 Langford 数列，结果却怎么也找不到。后来才知道， n = 5 时的 Langford 数列根本就不存在。这是为什么？你能证明这一点吗？
日常生活中经常会出现这样的场景：你想在数据库上查询某个东西，但却不希望留下线索，让别人知道你查询了什么。比方说，投资人可能会在数据库上查询某支股票的信息，但却不希望任何人知道他感兴趣的股票究竟是哪一支。看上去，似乎唯一的办法就是把整个数据库全部拷回家。然而，这些数据往往都拥有非常庞大的体积，全部拷走通常都是很不现实的；另外，考虑到数据内容的隐私性和数据本身的宝贵价值，数据的持有者通常也不允许其他人把整个数据全盘拷走。不过，随着分布式数据库的广泛应用，上面的难题有了一个两全其美的好办法：假设有两个内容完全相同的数据库，投资人可以先在第一个数据库上执行一个不会透露目的的查询，再在另一个数据库上执行另一个不会透露目的的查询，两次查询结合起来便能推出想要的结果。只要没有人刻意去收集并且对比两个数据库的查询记录，那么谁也不会知道投资人真正想要查询的是什么。在这个背景下，我们有了下面这个有趣的问题。
服务器随机产生了一个 {1, 2, …, 100} 的子集 S ，并且同时发送给了 A 和 B 两名前台工作人员。 A 、 B 两名前台都接受其他人的提问，但为了保护数据，两个人都只能用“是”或者“否”来回答问题，并且都不允许同一个人重复提问。你非常关心某个数 n 是否在这个子集里。其实，你本来可以直接问 A 和 B 中的任何一个人“数字 n 是否在集合 S 里”，但是这样一来，对方就知道了你想要查询的是什么。为此，你可以向 A 和 B 各问一个问题（结合两人的回答便能推出集合 S 里是否包含数字 n ），但却不能让 A 和 B 当中的任何一个人知道你查询的是哪个数（我们假设 A 、 B 两人不会串通起来，把他们各自收到的问题联系在一起）。事实上，你需要保证 A 和 B 两人都不能从你的问题中获取到任何信息，也就是说，对于 A 和 B 当中的任何一个人来说，各种问题出现的概率不会随着 n 值的改变而改变。再换句话说，如果 n 的值变了，那么 A 和 B 各自将会听到的问题应该拥有和原来相同的概率分布。