剪燈閒筆: 剪裁边缘

双鱼香草咖啡（一）

Wed, 02 Jan 2008 17:49:15 GMT

【分类】计算机 » 编程语言 » Java
【标签】JDK | 线程安全

下面是 java.awt.Component 的代码片段，用于获取当前组件的背景色。

public Color getBackground() {

Color background = this.background;

if (background != null) {

return background;

}

// ...

}

初次读到这里时，想不明白 Color background = this.background; 这条语句的用意，第一个反应这是 JDK 经过多次版本变迁后不经意留下的代码碎片。这理由很快就被否定，原因是 Component 类中有大量类似的语句，很难想象 JDK 程序员会对如此频繁出现的冗余代码熟视无睹。既然这样，那这条语句必定有它的作用，我又想到四条理由：一是为了遵循与相似代码一致的代码风格；二是为了边际代码的安全，防止日后由于疏忽或误解而对代码做出错误的改动；三是为了将来需要扩展时，不必更改过多的代码；四是为了提高代码的执行效率，进行编译器顾及不到的优化。这四条理由都可能导致非常规代码的产生，但这里显然又都不是。

想了一小会，几乎要放弃的时候，我突然意识到这可能和线程安全有关。这么一想，思路豁然开朗。用局部变量 background 代替域变量 background 可以防止程序执行了 background != null 的判别后可以进入但还没有进入 return background; 时被别的线程修改了域变量 background 的值。否则，这两处的 background 可能不同值，那么 background != null 的保护性判别就失去了意义。

问题似乎该结束了，但有一个问题，如果上面的情形真的发生，即当前线程准备执行 return background; 时被另一线程修改了域变量 background 的值，则当前线程的 getBackground() 返回的值并不能反映最新的 background 的变化，所以这里的线程安全有瑕疵。要解决这个问题，简单的办法是用 synchronized 对这块临界区加锁，Component 类中就有大量这样的例子。但是同时，我们知道，synchronized 是很影响性能的，getBackground() 由于只涉及到对域变量 background 的读操作，所以没有必要加锁。也说是说，getBackground() 的实现也只能象上面那样——因为没有简单的办法做到更完美。

但我还是找到一个办法让问题变得简单，这需要扩展 Java 语法。如果我们有两个同步关键字：读同步 readsync 和写同步 writesync。当两个线程都进入 readsync 临界区时，互不加锁；当一个线程位于 readsync 临界区，另一个线程企图进入 writesync 临界区，或者反过来，一个线程位于 writesync 临界区，另一个线程企图进入 readsync 临界区，或者两个线程都企图进入 writesync 临界区时，实现同步。这既可以解决上面的线程安全问题，又不损失性能。更精细地，readsync 和 writesync 不仅像 synchronized 那样能同步类和对象，还能同步类的域变量，比如上例，即用 readsync(background) 来同步域变量 background。

如果不扩展 Java 语法，也可以通过改进编译器来实现上述设想。仍用 synchronized 来标识，编译器自动分析临界区内哪些域变量是读同步，哪些是写同步，这不困难。困难的是，编译器无法知道临界区内哪些域变量是无须同步的。

关于汤姆孙灯问题的解释

Tue, 04 Dec 2007 15:12:05 GMT

【分类】数学 » 数学分析 | 哲学

【标签】汤姆孙灯 | 芝诺悖论 | 阿喀琉斯悖论

汤姆孙灯^【1】（Thomson's Lamp）问题是 James Thomson 1954 年在 Analysis 第 15 期中提出的，文章题为 Tasks and super-tasks，也收录在 Martin Gardner 的 Aha! Gotcha: Paradoxes to Puzzle and Delight (Tools for Transformation)（《从惊讶到思考——数学悖论奇景》）第六章《超级任务》中。问题是这样描述的：

一盏灯由一个开关控制。把灯开 1 分钟，再关 ½ 分钟，再开 ¼ 分钟，再关 ⅛ 分钟，……如此进行下去。试问，两分钟后灯是开着还是关着？

许多时候，这个问题和芝诺悖论（Zeno's Paradoxes）中的阿喀琉斯悖论（Achilles and the Tortoise）联系在一起。阿喀琉斯悖论说的是古希腊神话英雄阿喀琉斯（Ἀχιλλεύς，Achilles）和乌龟赛跑，阿喀琉斯让乌龟先跑一段距离，然后从后面追赶。假定阿喀琉斯起跑时，乌龟已爬到 A。当阿喀琉斯跑到 A 时，乌龟又爬到 B，当阿喀琉斯跑到 B 时，乌龟又爬到 C，……也就是说，乌龟总是爬在阿喀琉斯前面，从而得出阿喀琉斯永远赶不上乌龟的结论。

阿喀琉斯悖论当然有违常理。级数计算表明，A, B, C, ... 组成的序列是收敛的，阿喀琉斯最终能追上乌龟。难道芝诺的推理有问题？没有！芝诺的推理逻辑是严密的，没有漏洞。那漏洞在哪呢？不少人认为芝诺的推理有一个隐含的假设，即空间的无限可分性。如果否定空间的无限可分性，那阿喀琉斯悖论就不攻自破了。我认为这种解释并不妥当，有两个原因。一是物理世界的空间是不是无限可分的，目前无从知晓；二是即使空间是无限可分的，阿喀琉斯悖论也不成立。

我们假设阿喀琉斯在 Z 处追上乌龟。如果空间是无限可分的，那么 A 和 Z 可以理解为实数轴上的两点。康托（Cantor）告诉我们，A 和 Z 之间有无穷多个点，并且这些点的个数和实数的基数一样，为。另一方面，A, B, C, ... 也是个无穷序列，这个序列中的点的个数和自然数的基数相等，为。这就引发了一个矛盾：芝诺试图用可数的 {A, B, C, ...} 去度量不可数的 [A, Z)。由于前者的基数比后者的小，用前者度量后者，结果只能是∞。这里的∞对应了阿喀琉斯永远赶不上乌龟。

解决了阿喀琉斯悖论，我们回到汤姆孙灯问题。汤姆孙灯问题看起来和阿喀琉斯悖论有些相似，都涉及到无穷级数求和，共同的疑惑都是到达极限和之前存在着无休止的阻尼振荡运动，这个运动不会终结，所以问题看似不可解。

这种类比也许有理，但仅仅是表面现象，汤姆孙灯问题远没有阿喀琉斯悖论深刻和复杂。实际上，汤姆孙灯问题只是一个简单的函数求值问题。我们用 f(t) 表示 t 时刻汤姆孙灯的开关状态，f(t)=1 表示开，f(t)=0 表示关。显然，原题等价于求解 f(2) 的值。f(2) 是多少，我们不知道，因为原题只给出了 f(t), t∈[0,2) 的定义。也就是说，f(2) 是没有定义的！如此而已。

我们又问，这样的话，我们就可以随意地定义 f(2) 为 0 或 1 了。那不是说，无论 f(2) 为何值，f(t) 总能依上面的开关规则过渡到 f(2)？换句话说，f(1.∞)^【2】既可以为 0，也可以为 1？这不是矛盾吗？

确是如此！因为当 t=1.∞ 时，开与关的时间间隔已经减小到 0 了。既然是 0，那此时无论灯是开着还是关着，都可以在没有时间损耗的前提下切换到另一状态。f(1.∞) 的确既等于 0，又等于 1。这违反了单值函数的定义，所以 f(t) 当 t→2^- 时的极限不存在。也就是 f(t) 在 t=2 附近不连续。

至此，我们得到汤姆孙灯在两分钟这个时刻：

(1) 其状态数学上无意义；

(2) 既是开着，也是关着。

两个结果任选其一，都是正确的，含义不同罢了。

对于第二个结果，也许有人会问：一盏灯怎么可能既是开着又是关着？是的，是有点超乎想象，但理论上确是可能的。如果再问：现实中这种情况也能发生吗？我想现实中不会存在这种开关不需要时间的灯。话说回来，如果这种开关出现在微观世界里，那不好说了，也许量子真有能耐改变了状态却不消耗时间。之所以这么说，因为我感觉这一概念似乎有助于解释奇异的电子双缝实验。

【1】Thomson 这个名字有四种常见的译法：汤姆逊、汤姆孙、汤姆森和汤姆生，不知哪种是标准译名。比照 Edison 译为爱迪生，Simpson 译为辛普森，Amazon 译为亚马孙（逊），似乎后缀 -son / -zon 没有固定译法。汤姆生这个译名比较少见，汤姆森更适用于 Thomsen，亚马逊已被标准化为亚马孙。因此这里我选择了个人认为最合适的汤姆孙。

【2】f(1.∞) 表示 lim f(t), t→2^-。

哈泽德的难题

Thu, 08 Nov 2007 19:34:52 GMT

【分类】数学 » 算术 | 数学 » 数学游戏

【标签】算式题 | Martin Gardner

下面的算式题（Cryptarithm Multiplication Problem）来自 Harry Hazard，收录于 Scientific American（《科学美国人》）著名专栏作家 Martin Gardner（马丁·加德纳）主持的 Mathematical Games 1967 年的结集出版物 Numerology of Dr. Matrix。该书 1976 年再版时扩充并更名为 The Incredible Dr. Matrix，1985 年再次扩充并更名为 The Magic Numbers of Dr. Matrix。

LYNDON

JOHNSON

算式中相同的字母代表相同的数字，不同的字母代表不同的数字，并且被乘数和积的最高位不能为零。

这道题有几个巧妙的地方。题面上看，它嵌入了美国总统 Lyndon B. Johnson（林登·贝恩斯·约翰逊）的名字；推导而言，它只需要浅显的算术知识，但是求解过程并不简单；更加难得地是，这道题竟然有唯一的答案。

我们来试着解决这个问题。

1 已知：b,d,h,j,l,n,o,s,y 为互不相等的整数，且 0≤b,d,h,n,o,s,y≤9，1≤j,l≤9。

2 显然，b≠0,1，即 b≥2。否则，算式不成立。

3 我们从低位开始依次建立等式。

3.1 考虑算式的最末位，有：nb=10x₁+n，即 n(b-1)=10x₁。因为 0≤n≤9，b≥2，n≠b，所以 (n,b) 可能的取值为 (0,2), (0,3), (0,4), (0,5), (0,6), (0,7), (0,8), (0,9), (2,6), (5,3), (4,6), (5,7), (5,9), (8,6)。

3.2 考虑算式的末两位，有：(10o+n)b=100x₂+10o+n，即 (10o+n)(b-1)=100x₂。

3.2.1 若 n=0，则 10o(b-1)=100x₂，即 o(b-1)=10x₂。由 0≤o≤9，o≠n 得，(o,b) 可能的取值为 (2,6), (5,3), (4,6), (5,7), (5,9), (8,6)。即 (o,n,b) 可能的取值为 (2,0,6), (5,0,3), (4,0,6), (5,0,7), (5,0,9), (8,0,6)。

3.2.2 若 b=6，则 (10o+n)×5=100x₂，即 10o+n=20x₂。由此可知 10|n，因为 0≤n≤9，所以 n=0。见 3.2.1。

3.2.3 若 n=5，则 (10o+5)(b-1)=100x₂，即 (2o+1)(b-1)=20x₂。因为 2o+1 为奇数，所以 4|b-1。由 b≥2，b≠n 知 b=9。从而，o=2 或 7。即 (o,n,b) 可能的取值为 (2,5,9), (7,5,9)。

综合 3.2.1、3.2.2 及 3.2.3 得，(o,n,b) 可能的取值为 (2,0,6), (5,0,3), (4,0,6), (5,0,7), (5,0,9), (8,0,6), (2,5,9), (7,5,9)。

3.3 考虑算式的末四位，有：(1000n+100d+10o+n)b=10000x₃+1000n+100s+10o+n，即 100db+(1001n+10o)(b-1)=10000x₃+100s。

3.3.1 若 n=0，则 100db+10o(b-1)=10000x₃+100s，即 db+o(b-1)/10=100x₃+s，即 100|db+o(b-1)/10-s。因为 db+o(b-1)/10-s<100，所以 db+o(b-1)/10-s=0。

3.3.1.1 若 (o,b)=(2,6)，则 6d+1-s=0。因为 d≠n，所以 d≠0，从而 d=1，s=7。即 (d,s,o,n,b) 可能的取值为 (1,7,2,0,6)。

3.3.1.2 若 (o,b)=(5,3)，则 3d+1-s=0。因为 d≠n，所以 d≠0，从而 d=1，s=4 或 d=2，s=7。即 (d,s,o,n,b) 可能的取值为 (1,4,5,0,3), (2,7,5,0,3)。

3.3.1.3 若 (o,b)=(4,6)，则 6d+2-s=0。因为 d≠n，所以 d≠0，从而 d=1，s=8。(d,s,o,n,b) 可能的取值为 (1,8,4,0,6)。

3.3.1.4 若 (o,b)=(5,7)，则 7d+3-s=0。因为 d≠n，所以 d≠0。无解。

3.3.1.5 若 (o,b)=(5,9)，则 9d+4-s=0。因为 d≠n，所以 d≠0。无解。

3.3.1.6 若 (o,b)=(8,6)，则 6d+4-s=0。因为 d≠n，所以 d≠0。无解。

3.3.2 若 (n,b)=(5,9)，则 900d+8(5005+10o)=10000x₃+100s，即 90d+4004+8o=1000x₃+10s，即 100|9d+(2002+4o)/5-s。

3.3.2.1 若 o=2，则 100|9d+402-s。因为 393≤9d+402-s≤483，所以 9d+402-s=400，即 9d+2-s=0。因为 s≠o，所以 s≠2。无解。

3.3.2.2 若 o=7，则 100|9d+406-s。因为 397≤9d+406-s≤487，所以 9d+406-s=400，即 9d+6-s=0。从而 d=0，s=6。即 (d,s,o,n,b) 可能的取值为 (0,6,7,5,9)。

综合 3.3.1 及 3.3.2 得，(d,s,o,n,b) 可能的取值为 (1,7,2,0,6), (1,4,5,0,3), (2,7,5,0,3), (1,8,4,0,6), (0,6,7,5,9)。

3.4 考虑算式的末五位，有：(10000y+1000n+100d+10o+n)b=100000x₄+10000h+1000n+100s+10o+n，即 10000yb+100db+(1001n+10o)(b-1)=100000x₄+10000h+100s。

3.4.1 若 n=0，则 10000yb+100db+10o(b-1)=100000x₄+10000h+100s，即 yb+(db+o(b-1)/10-s)/100=10x₄+h。由 3.3.1 知 db+o(b-1)/10-s=0，所以 10|yb-h。

3.4.1.1 若 b=6，则 10|6y-h。

3.4.1.1.1 若 (d,s,o)=(1,7,2)，因为 y≠b，y≠s，h≠n，y≠h，所以 (y,h) 可能的取值为 (3,8), (9,4)。即 (y,h,d,s,o,n,b) 可能的取值为 (3,8,1,7,2,0,6), (9,4,1,7,2,0,6)。

3.4.1.1.2 若 (d,s,o)=(1,8,4)，因为 y≠d，h≠s，h≠o，h≠n，y≠h，所以 (y,h) 可能的取值为 (7,2)。即 (y,h,d,s,o,n,b) 可能的取值为 (7,2,1,8,4,0,6)。

3.4.1.2 若 b=3，则 10|3y-h。

3.4.1.2.1 若 (d,s,o)=(1,4,5)，因为 y≠b，y≠s，h≠b，h≠d，h≠s，y≠h，所以 (y,h) 可能的取值为 (2,6), (6,8), (9,7)。即 (y,h,d,s,o,n,b) 可能的取值为 (2,6,1,4,5,0,3), (6,8,1,4,5,0,3), (9,7,1,4,5,0,3)。

3.4.1.2.2 若 (d,s,o)=(2,7,5)，因为 y≠b，y≠d，y≠s，h≠b，h≠d，h≠s，y≠h，所以 (y,h) 可能的取值为 (6,8), (8,4)。即 (y,h,d,s,o,n,b) 可能的取值为 (6,8,2,7,5,0,3), (8,4,2,7,5,0,3)。

3.4.2 若 (d,s,o,n,b)=(0,6,7,5,9)，则 9y+4=10x₄+h。即 10|9y+4-h。因为 y≠d，y≠s，y≠n，h≠d，h≠s，h≠n，y≠h，所以 (y,h) 可能的取值为 (1,3), (3,1)。即 (y,h,d,s,o,n,b) 可能的取值为 (1,3,0,6,7,5,9), (3,1,0,6,7,5,9)。

综合 3.4.1 及 3.4.2 得，(y,h,d,s,o,n,b) 可能的取值为 (3,8,1,7,2,0,6), (9,4,1,7,2,0,6), (7,2,1,8,4,0,6), (2,6,1,4,5,0,3), (6,8,1,4,5,0,3), (9,7,1,4,5,0,3), (6,8,2,7,5,0,3), (8,4,2,7,5,0,3), (1,3,0,6,7,5,9), (3,1,0,6,7,5,9)。

3.5 考虑整个算式，有：(100000l+10000y+1000n+100d+10o+n)b=1000000j+100000o+10000h+1000n+100s+10o+n，即 100000lb+10000yb+100db+(1001n+10o)(b-1)=1000000j+100000o+10000h+100s。

3.5.1 若 (y,h,d,s,o,n,b)=(3,8,1,7,2,0,6)，则 6l=10j+1。因为左式为偶，右式为奇，所以无解。

3.5.2 若 (y,h,d,s,o,n,b)=(9,4,1,7,2,0,6)，则 6l=10j-3，因为左式为偶，右式为奇，所以无解。

3.5.3 若 (y,h,d,s,o,n,b)=(7,2,1,8,4,0,6)，则 6l=10j。因为 l≠j，所以 (l,j) 可能的取值为 (5,3)。即 (l,j,y,h,d,s,o,n,b)=(5,3,7,2,1,8,4,0,6)。

3.5.4 若 (y,h,d,s,o,n,b)=(2,6,1,4,5,0,3)，则 3l=10j+5，即 l=5，j=1。因为 l≠o，所以无解。

3.5.5 若 (y,h,d,s,o,n,b)=(6,8,1,4,5,0,3)，则 3l=10j+4，即 l=8，j=2。因为 l≠h，所以无解。

3.5.6 若 (y,h,d,s,o,n,b)=(9,7,1,4,5,0,3)，则 3l=10j+3，即 l=1，j=0。因为 l≠d，所以无解。

3.5.7 若 (y,h,d,s,o,n,b)=(6,8,2,7,5,0,3)，则 3l=10j+4，即 l=8，j=2。因为 l≠h，所以无解。

3.5.8 若 (y,h,d,s,o,n,b)=(8,4,2,7,5,0,3)，则 3l=10j+3，即 l=1，j=0。因为 j≠n，所以无解。

3.5.9 若 (y,h,d,s,o,n,b)=(1,3,0,6,7,5,9)，则 9l=10j+6，即 l=4，j=3。因为 j≠h，所以无解。

3.5.10 若 (y,h,d,s,o,n,b)=(3,1,0,6,7,5,9)，则 9l=10j+4，即 l=6，j=5。因为 l≠s，所以无解。

综合 3.5.1 至 3.5.10 可知，本题有唯一解 (l,j,y,h,d,s,o,n,b)=(5,3,7,2,1,8,4,0,6)，即：

570140

3420840

❏检验程序

Python

# Hazard Problem by Roy Fang <royfang@hotmail.com>

l = 10

a = range(l)

def permute(n):

if n > 1:

for i in range(n):

if i > 0:

m = n - 1 if n == 2 or n % 2 else i - (i == n - 1)

a[-n], a[-m] = a[-m], a[-n]

if (n == l or i > 0) and (a[0] > 0 and a[5] > 0 and a[6] > 0):

concatenate = lambda *s: reduce(lambda x, y: x * 10 + y, s)

p = concatenate(a[0], a[1], a[2], a[3], a[4], a[2])

q = a[5]

r = concatenate(a[6], a[4], a[7], a[2], a[8], a[4], a[2])

if p * q == r:

print p, '*', q, '=', r

permute(n - 1)

permute(l)

最后修订：2008-4-30

无处不在的相似

Tue, 30 May 2006 04:47:34 GMT

【分类】数学 » 分形

【标签】L 系统 | IFS

彭罗斯镶嵌（Penrose Tiles）：许多人通过罗杰·彭罗斯（Roger Penrose）的《皇帝新脑》（The Emperor's New Mind）认识彭罗斯镶嵌。彭罗斯镶嵌是非周期平面镶嵌的例子，也是迄今这类镶嵌的最简形式——只用一对花砖即可非周期地铺满整个平面。下图的花砖被称为 thick rhombus 和 thin rhombus。书中还有一种镶嵌方法更为知名，其花砖被称为 kite 和 dart。实际上，这两种方法完全等价，并且可以相互转换。

希尔伯特曲线（Hilbert Curve）：完全覆盖平面的曲线。类似的还有皮亚诺曲线（Peano Curve），只是皮亚诺曲线需要动画才有较好的视觉效果。

Koch 雪花（Koch Snowflake）

龙曲线（Dragon Curve）

谢尔宾斯基曲线（Sierpinski Sieve、Sierpinski Carpet、Sierpinski Arrowhead Curve）

更多曲线

灌木

蕨类植物：Barnsley's Fern 群

树

山

屏幕刻度尺

Sat, 20 May 2006 00:43:55 GMT

【分类】计算机 » 软件 » 图形图像

【标签】刻度尺

漂亮的半透明屏幕刻度尺。程序设计参考了 Jeff Key 的同题作品，特此感谢。

本软件需要 Microsoft .NET Framework 2.0 支持。

C# 和 Java 中不规范的隐式类型转换

Thu, 09 Feb 2006 23:29:49 GMT

【分类】计算机 » 编程语言

【标签】C# | Java | 隐式转换

C# 2005 有一值得商榷的类型转换问题。

我们知道，double 到 int 的转换必须是显式的，否则会出现编译错误。但是下面的语句却可以正常编译而得不到任何错误或警告信息。

foreach (int value in new double[] { 0.5, 1.5 }) { }

查看 IL 可知，编译器在此进行了隐式转换：

ldelem.r8

conv.i4

这似乎不符合 C# Language Specification 3^rd Edition 13.2.1 的描述。

Java 5.0 也有类似的问题：

int value = 1; value = value + 0.5;

无法通过编译，而

int value = 1; value += 0.5;

却可以顺利编译，也不会有任何警告信息。

查看 Bytecode 可知，编译器在此也进行了隐式转换：

iconst_1

istore_0

iload_0

i2d

ldc2_w 0.5

dadd

d2i

istore_0

天平分堆问题

Wed, 08 Feb 2006 00:00:18 GMT

【分类】数学 » 组合数学 | 计算机 » 算法

【标签】天平 | 砝码 | 分堆问题

问题：现有一台无刻度的天平和质量为 2 克、7 克的砝码各一只。要求只称三次，将 140 克的盐分为 50 克和 90 克两堆。

此题难度不高，网上能找到的答案也是五花八门，不过要得到全部的答案，也不是轻松的事。

容易知道，类似的天平称重问题一般涉及两类已知量，一类是可分可合的量，如题中的盐；另一类是不可变动的量，如题中的砝码。每一次称重，我们所做的操作无非是以下二者之一：(1) 将物品置于天平两端，物品总量已知；(2) 只将物品置于天平一端。不论哪项操作，都允许在天平两端放上零个或多个砝码。

假定当前分堆集合为 S_n，原始砝码集合为 W₀，我们选择 S_n 的子集 P 进行新的分堆，用 t 表示 P 的总质量，t>0。而不在 P 中的 S_n 的分堆可以临时作为砝码使用，即 W_n=W₀∪(S_n-P)。

再设称重时天平左端物品质量为 x，砝码为 a，右端物品质量为 y，砝码为 b，那么天平平衡的条件是 x+a=y+b。不妨设 x≥y，从而 a≤b。因为 x=0 及 x=t 无意义，我们有 0<x<t。于是上面两种称重方法可以表示为两个方程组：

① x+a=y+b, x+y=t, y>0

② x+a=y+b, 0<x<t, y=0

解得：

① x=(t+(b-a))/2, y=(t-(b-a))/2, y>0

② x=b-a, 0<x<t, y=0

令 r=b-a，解简化为：

① x=(t+r)/2, y=(t-r)/2, y>0

② x=r, 0<x<t, y=0

从而得到新的分堆：Q={x,y} 或 Q={x,t-x}，且 S_n+1=S_n-P+Q。

回到原题，根据前面分析可知，S₀={140}，W₀={2,7}，R₀={0,2,5,7,9}。将 S、R 代入方程组①②得：

(X,Y)={(70,70),(71,69),(72½,67½),(73½,66½),(74½,65½),(2,0),(5,0),(7,0),(9,0)}

这就是第一次称重能得到的全部分堆。

构造新的 S 和 R，重复解方程组①②得到第二、三次分堆。结果如下：

0	1	2	3
S={140} R={0,2,5,7,9}	(x,y)=(70,70) S={70,70} R={0,2,5,7,9,61,63,65,68,70, 72,75,77,79}	(x,y)=(35,35) S={35,35,70} R={0,2,5,7,9,26,28,30,33,35, 37,40,42,44,61,63,65,68,70, 72,75,77,79,96,98,100,103, 105,107,110,112,114}	(x,y)=(17½,17½) S={17½,17½,35,70}
此处略去 39770 行……

最后，从第三次称重后的 S 中取出和为 50（或 90）的若干分堆，即是问题的答案，共 63 解。

	1	2	3
1	(5,135)	(5,14,121)	(5,14,50,71)
2	(5,135)	(5,64,71)	(5,14,50,71)
3	(5,135)	(5,64,71)	(5,21,50,64)
4	(7,133)	(7,12,121)	(7,12,50,71)
5	(7,133)	(7,14,119)	(7,14,50,69)
6	(7,133)	(7,62,71)	(7,12,50,71)
7	(7,133)	(7,62,71)	(7,21,50,62)
8	(7,133)	(7,63,70)	(7,27,43,63)
9	(7,133)	(7,64,69)	(7,14,50,69)
10	(7,133)	(7,64,69)	(7,19,50,64)
11	(9,131)	(9,11,120)	(9,11,50,70)
12	(9,131)	(9,16,115)	(9,16,25,90)
13	(9,131)	(9,16,115)	(9,16,34,81)
14	(9,131)	(9,18,113)	(9,18,23,90)
15	(9,131)	(9,18,113)	(9,18,32,81)
16	(9,131)	(9,18,113)	(9,18,50,63)
17	(9,131)	(9,60,71)	(9,30,41,60)
18	(9,131)	(9,61,70)	(9,11,50,70)
19	(9,131)	(9,61,70)	(9,20,50,61)
20	(9,131)	(9,63,68)	(9,13,50,68)
21	(9,131)	(9,63,68)	(9,18,50,63)
22	(9,131)	(9,63,68)	(9,27,41,63)
23	(65½,74½)	(18,56½,65½)	(18,32,33½,56½)
24	(66½,73½)	(16,57½,66½)	(16,32½,34,57½)
25	(69,71)	(5,64,71)	(5,14,50,71)
26	(69,71)	(5,64,71)	(5,21,50,64)
27	(69,71)	(7,62,71)	(7,12,50,71)
28	(69,71)	(7,62,71)	(7,21,50,62)
29	(69,71)	(7,64,69)	(7,14,50,69)
30	(69,71)	(7,64,69)	(7,19,50,64)
31	(69,71)	(9,60,71)	(9,30,41,60)
32	(69,71)	(11,60,69)	(11,21,39,69)
33	(69,71)	(11,60,69)	(11,30,39,60)
34	(69,71)	(30,39,71)	(11,30,39,60)
35	(69,71)	(30,39,71)	(21,30,39,50)
36	(69,71)	(31,38,71)	(12,19,38,71)
37	(69,71)	(31,38,71)	(12,31,38,59)
38	(69,71)	(31,38,71)	(19,19,31,71)
39	(69,71)	(31,38,71)	(19,31,38,52)
40	(69,71)	(31,38,71)	(21,31,38,50)
41	(69,71)	(31,38,71)	(31,50,59)
42	(69,71)	(31,38,71)	(38,50,52)
43	(69,71)	(31,40,69)	(10,31,40,59)
44	(69,71)	(31,40,69)	(19,21,31,69)
45	(69,71)	(31,40,69)	(19,31,40,50)
46	(69,71)	(31,40,69)	(31,50,59)
47	(69,71)	(31,40,69)	(40,50,50)
48	(69,71)	(32,37,71)	(18,32,37,53)
49	(69,71)	(32,39,69)	(11,21,39,69)
50	(69,71)	(33,38,69)	(12,21,38,69)
51	(69,71)	(33,38,69)	(12,33,38,57)
52	(69,71)	(33,38,69)	(17,33,38,52)
53	(69,71)	(33,38,69)	(19,33,38,50)
54	(69,71)	(33,38,69)	(33,50,57)
55	(69,71)	(33,38,69)	(38,50,52)
56	(70,70)	(7,63,70)	(7,27,43,63)
57	(70,70)	(9,61,70)	(9,11,50,70)
58	(70,70)	(9,61,70)	(9,20,50,61)
59	(70,70)	(34,36,70)	(16,34,36,54)
60	(70,70)	(35,35,70)	(15,20,35,70)
61	(70,70)	(35,35,70)	(15,35,35,55)
62	(70,70)	(35,35,70)	(20,35,35,50)
63	(70,70)	(35,35,70)	(35,50,55)

【问题延续】如何利用这台的天平和 2 克、5 克的砝码。只称三次，将 237 克的盐分为 80 克和 157 克两堆？

朝花夕拾

Mon, 30 Jan 2006 00:59:58 GMT

【分类】计算机 » 软件

【标签】世界国旗 | 电子邮件图标 | 屏幕放大镜

收拾陈年代码，感叹尽是黔之驴一类的蠢物。当时好事为之，毕则无可用，束之高阁。尘积霉滋，虫蚀鼠啮，日渐散佚，乃至殆尽。今借新年暖阳，拾其善者而曝之，聊尽凉主寸心。

World Flag：世界国旗区旗。尽可能遵照各国国旗法规定，包括尺寸、配色、图案等。优先采用数学运算，法定造型不详或资料缺乏的，退用矢量模拟。支持无失真缩放、旋转及其它变型。

绘制五星红旗时有两点颇感到意外：

一、中华人民共和国国旗法只规定国旗旗面为红色，没有说明是哪一种红。据说有《国旗》和《国旗颜色标准样品》两项国标，网上无法查到。有一点几乎可以断言，这种红不是 RGB 值为 FF0000 的纯红。如果真是如此，香港特别行政区政府网站上的香港区旗就是错误的，因为《区旗及区徽条例》规定，区旗旗面为红色，其色度值以中华人民共和国国旗红为标准；

二、可能考虑到绘制的方便，旗面上的四颗小星并不关于大星上下对称。

Mail Icon：电子邮件图标。形如此空间首页档案下方的图样地址。这个小程序完全模仿 E-Mail Icon Generator 而作，甚至也写成 ISAPI 形式，以致无处安置。虽然提供某些前作不支持的域名，譬如搜狐，也允许自定义扩展，还设想实现更丰富的边框底纹效果，但终究是拾人牙慧缺乏创见的习作。

Fairview：屏幕放大镜。相对于汗牛充栋的同类软件，技术上，采用钩子比定时器高效简洁些。但也有缺点，不能自觉感应屏幕变化。功能上，常用于对页面布局和图像色彩进行微调。

英文文档中的中文乱码

Tue, 10 Jan 2006 02:51:35 GMT

【分类】计算机 » 编码

【标签】乱码 | 抯 | 字符编码

浏览英文网页，冷不丁会遇上个把中文乱码，或者残缺的 HTML 标签。这种情况一般出现在省字号（Apostrophe）和引号的位置上。解决的办法是将页面编码改为西欧字符。

之所以如此，原因在于不同字符集对扩展 ASCII 码的解释不同。以省字号为例，省字号实际上就是后单引号，即值为 A1AFH 的 GB2312 全角字符“’”，而不是值为 27H 的标准 ASCII 码字符“'”。Windows-1252（通常浏览器以 Windows-1252 替代西欧字符集 ISO-8859-1）中，省字号的 ASCII 码值为 92H。当操作系统缺省语言为简体中文时，浏览器将 ASCII 码值 92H 视为 GBK 字符的高字节，连同紧挨着省字号的字节一起，被解释为一个汉字显示出来。因此，英文页面中的’s（9273H）在简体中文下显示为“抯”。

双引号和连字符也是这样。

数据共享与信息关联

Mon, 03 Oct 2005 00:02:49 GMT

【分类】计算机 » 信息学

【标签】数据 | 共享 | 关联

用 BitTorrent 和 eMule 并行下载同一文档，初衷只是慢中取快。但当传输行进到一定时刻，两份不完全拷贝必定相互包含对方尚未完成的数据块，此时自然希望能有工具将二者的有效成分拼接起来。

略进一步，仅仅拼接——包括同属残块（如 BitTorrent 之间）和异属残块（如 eMule 与 FlashGet 之间）的拼接（这里之所以称“属”而不称“种”，是因为同一类软件往往有多种衍生品和版本，它们的数据组织方式不尽相同）——尚显不足，有时还需要对不同数据残块进行转换，特别当一类数据源撤消而另一类数据源存在时。

更进一步，下载过程一般包含三个阶段的工作：连接、传输和数据组织。数据组织位于末端，在此桥接最为简便，但效率也是最低。于是考虑这样一个整合平台，能同时支持各类连接和传输协议，能实时进行异种数据片的校验和包装，能在全网视野下维持各片数据的动态均衡，甚至借助空闲的公用服务器和带宽进行数据中转。

再深一层，上面的平台已具有简单分布式操作系统的特征，而且既可以采用点对点对等网络模式，也可以设立中央计算机进行任务分配和均衡负载。但是，这里缺少一个环节，就是如何收集散落在网络空间里的数据源。一个直观的想法是建立专用搜索引擎，使用爬虫汇聚和更新实时信息，并借助缓存在一定时段内维持其有效性。

继续挖掘，依靠爬虫收集信息显然是被动的，难以避免信息完整性和时效性的问题。这就要求建立一种机制，能够主动接收数据源发布的信息，利用集群系统辅以网格计算技术完成异构环境下的信息采集、调度和管理，并解决数据安全等问题。

未曾结束，上面描述的信息是静态的、独立的，相互间缺少联系，然而现实不是这样。譬如一份文档，可以以文本形式存在，也可以表现为格式文件，还可以加密压缩。再如一本书，可以分为若干章节，各章又包含若干页面。这些页面可以独立存在于数据源中，也可以作为全书的一部分存在于数据源。这两个例子说明，数据源间存在多种层次多种表现形式，这就需要一种策略，能够对数据进行智能分层分类，自动抽取摘要，选择性滤除冗余信息，并对相关数据进行相似性估计。这一点上，Ontology 元数据系统和形式概念分析（Formal Concept Analysis）技术也许能部分地解决问题。

陆与陆本是相连的，然而粘合处深埋水底，于是我们在河上搭桥。桥面太窄，流量受限，又不能及远，于是我们在桥间建岛。桥和岛多了，相近的彼此相连，于是形成新的陆地。陆地不断扩张，久而久之，其间不再有空隙，于是地球成为一块实地。

标识符命名规则

Thu, 01 Sep 2005 03:59:19 GMT

【分类】计算机 » 编程语言

【标签】标识符 | 命名

计算机语言发展至今，标识符命名逐渐摆脱了早期不区分大小写的书写样式，以及微软借 Windows 平台推荐和推广的匈牙利命名法，形成目前主流的命名规则，包括以下四种样式：完全大写、完全小写、Pascal 大小写和 Camel 大小写。所谓 Pascal 大小写即组成标识符的每个单词的首字母大写，其余字母小写的书写约定；而 Camel 大小写与 Pascal 大小写相似，区别仅在于其标识符的首字母恒为小写。此外，作为上述规则的补充约定，对于双字母的缩写单词，Pascal 大小写要求它们全部大写，而 Camel 大小写则要求它们出现在标识符首部时全部小写，否则全部大写。需要强调，这条规则仅适用于缩写的双字母单词，象“To”、“Is”、“As”这样原生的双字母单词，不在此列。这点在 MSDN 中并未明确指出。

作为约定俗成，Java 语言中，完全大写用于常量的命名，完全小写用于包的命名，Pascal 大小写用于类和接口的命名，Camel 大小写则用于方法、局部变量和参数的命名。与此相较，C# 语言中，完全大写和完全小写不被使用。偶尔地，为保持与 C/C++ 语言的兼容，常量和枚举值可能采用完全大写的样式。除了保护字段、私有字段、局部常量、局部变量和参数采用 Camel 大小写外，名空间、类、结构、接口、异常、委托、特征、枚举类型、枚举值、事件、公共字段、静态字段、方法、属性和索引器均采用 Pascal 大小写。

撇开完全大写和完全小写的情形不谈，显而易见，Java 语言依据语义层次命名标识符：对于类型级别的标识符采用 Pascal 大小写，而对于对象级别的标识符则采用 Camel 大小写。这符合 OO 的抽象思想。与此不同，C# 依据可见性命名标识符：对于外部可见的标识符采用 Pascal 大小写，而对于外部不可见的标识符则采用 Camel 大小写。这符合 OO 的封装原则。孰优孰劣，殊难定论。若从学术角度探讨，Java 语言的命名规则似乎更为本质一些；但若从习俗角度论述，则 C# 语言的命名规则更显得亲和。

遗憾的是，尽管两类规则各执一辞，各自成理，但都同样存在逻辑缺陷。

Java 语言中，类的一般方法采用 Camel 大小写，但同样是方法的构造方法却因为要和类同名而不得不采用 Pascal 大小写。这显是 C++ 语言的遗风，只不知 Java 语言的设计者何以不借鉴 Pascal 语言为构造方法单独设计关键字以求得形式上的一致。C# 语言没有这一问题，但情况更糟。前文提及，C# 语言中，类的字段由于可见性的不同，可能采用 Pascal 大小写或者 Camel 大小写。但与字段相类的方法却不这样，其一律采用 Pascal 大小写。并且，由于嵌套类也可被修饰为保护型和私有型，那么，是不是它们的类名也应当采用 Camel 大小写？

此外，C# 语言虽然摒弃了匈牙利命名法，却保留匈牙利似前缀 I 作为接口的命名。类似的例外还出现在类的私有变量命名上，即便并非微软建议的规则，当前一种颇为流行的做法是为其添加前缀 m_，以区别于构造方法初始化列表中的参数名。这里的 m 表示 member，显然是 MFC 的命名风格。

瑕不掩瑜。回想起历史上关于变量名首字母是否应大写的问题曾引发旷日持久的激烈争论，如今这两类命名法却被优美地结合在一处。天下大势，分久必合，合久必分，诚如是也。

实形有别

Sun, 17 Jul 2005 20:28:26 GMT

【分类】计算机 » 编程语言

【标签】形参 | 实参 | Parameter | Argument

计算机语言中，Argument 和 Parameter 都有参数的意思，但两者有何区别，这个问题长时间困扰着我。依据 MSDN，命令行参数一般写作 Command-Line Arguments，main(int argc, char* argv[]) 和 Main(string[] args) 的函数原型也表达了同样的意思。但是，C# 定义方法的可变数目参数的关键字却是 params，而 .NET Framework 中有个异常类的名称又为 ArgumentException。这似乎表明这两个词可以互用。

偶然地，我在 C# Language Specification 定义栏里发现这样两段说明：

Argument - an expression in the comma-separated list bounded by the parentheses in a method or instance constructor call expression or bounded by the square brackets in an element access expression. It is also known as an actual argument.

Parameter - a variable declared as part of a method, instance constructor, operator, or indexer definition, which acquires a value on entry to that function member. It is also known as a formal parameter.

也就是说，Argument 表示实参的“参”，而 Parameter 表示形参的“参”。

听起来很有道理。对照上面例子，我恍然大悟，Main() 的 args 虽然出现在形参位置上，但它表示的却是命令行参数这个实参。

真是漂亮的结论！我几乎就要断言。

且等一等。

我接着翻阅 James Gosling 等的 The Java Language Specification。AWESOME！同 C# 的一样，这份规范书也严格遵循两个词的不同含义用法。

再查 Bjarne Stroustrup 的 The C++ Programming Language。不妙！变数出现了，书中无论实参形参，均写作 Argument。同时，还有这样的小说明：parameters (formal arguments)。这是不是说 Argument 可以替代 Parameter，而反之不可以？

转到 MSDN，情况更糟，大量存在 actual parameter 和 formal argument 的用法。

继续搜索 Google，休矣！两种用法的比例竟然相当。

默然良久……

从前述资料看，我想，Argument 和 Parameter 在一般语言环境下，确是可以互换，所以统一译为参数没有错误。但在严谨的学术氛围里，特别是近年，引申自数学，两个词还是有明确的区别：Argument 表示自变量，Parameter 则表示参变量。在侯捷的『英中繁简编程术语对照』也可以发现，Argument 台译为引数（极可能源来日译），Parameter 才译作参数。应当承认，这种分辨是有益的。

行文接近尾声的时候，我想到 .NET 中的另两个词：Property 和 Attribute。.NET 问世之初，这两个词的译法相当混乱。因为在以往计算机领域，它们的标准译名均为属性。现在中文 MSDN 把前者译为属性，后者译为特征，算是一种妥协的规范。但在 XPath 相关文档中，Attribute 仍被译为属性。历史问题真是无可奈何以极。

世界地理

Wed, 22 Jun 2005 06:05:42 GMT

【分类】计算机 » 图形学 | 地图学 » 球面投影

【标签】三维地球

试着转转 NASA World Wind，不意有了照虎画猫的想法。于是从最初的原理开始，单单空间变换方程的推导就耗费墨水若干。这样努力的结果就是现在的 World View，纯软件运算，未借助 DirectX 和 OpenGL，故对 CPU 有所要求。在我 2600+ 及 512M 的机器上，原始窗口动作尚称流畅，全屏则明显滞钝。这使得计划中的边缘抗锯齿和高阶插值无法虑及，旋转惯性亦将搁置。

标准测试图样可从这里下载，一是 Earth in True Color，一是 Earth at Night。如果想使用自己的图片，理想的效果要求图片尺寸大于窗口尺寸，长宽比为 2:1，左右边界颜色当无缝衔接，上下边界颜色呈弧状积聚，至极点处，对应的边线将收缩为一点。

修订历史

1.1 (2005-6-28)：无极缩放；调整控制键；调整程序结构。

1.0 (2005-6-22)：自由旋转。

麻将九听牌型

Thu, 26 May 2005 08:05:04 GMT

【分类】数学 » 组合数学 | 计算机 » 算法

【标签】九听 | 九莲宝灯

麻将基本听牌牌型中，有一类牌型能听遍一门花色的全部九张牌。上学有个时期对这类牌型感兴趣，手工构造了几种，但不完整。今天写个程序把十三张、十六张麻将所有听牌牌型穷举一遍，生成五十五万多行的数据，从中找出全部九听牌型。

十三张麻将九听牌型

九莲宝灯

十六张麻将九听牌型

第一组

第二组

第三组

【注】本文麻将单牌图像来自维基百科，属公共领域资源，不受版权保护。

简繁之思

Wed, 25 May 2005 02:56:05 GMT

【分类】文化 » 文字 » 汉字

【标签】简体字 | 繁体字

讨论简繁体字，不妨从名字说起。

汉字本没有简繁之分，只有正俗之分。正体字是官方认可的文字，俗体字则仅仅民间私行，不能用于正式场合。简体字大量取材于俗体字^【1】，而将正体字与异体字并置。由于简体字源自简化了的正体字，相对地，正体字就有了新的名字：繁体字。但这名字并不好，因为“繁”有冗而无用的意思，稍稍带有贬义。相比之下，英译名“Traditional Chinese”更为妥当。再有，称新的文字构型为“体”也有歧义。字体多指书法风格，象魏碑、行书、仿宋，这些都是字体却不是字形。

据此，个人观点，“繁体字”宜正名为“传统字”，“简体字”则正名为“简笔字”，才是贴切。

再试对简繁体字作一比较。

一、功用

作为信息的载体，文字最原始最根本的使命是记事和交流，而后才谈其余。

表达方面，简繁体字没有差异，几乎可以字字互换，或者词词互换。只是因为一简多繁^【2】和一繁多简^【3】现象的存在，以及部分人名^【4】、地名^【5】和学科术语^【6】的译异，计算机程序在无法正确分词和理解句意的情况下，还做不到缜密转换。

认知方面，个人认为，繁体字易于简体字。繁体字字形差异大，特征点多，又多具形声字结构，比单纯减少笔划却字形相似的简体字容易辨识。不过，这纯粹是主观感觉，公正的结论可以通过计算机OCR实验给出。

书写方面，简体字易于繁体字恐怕不会有异议。即便借助形声字优势，繁体字依然难记难写。

二、文化

追本溯源，汉字已有几千年的历史。从上古的结绳记事，到商周古字（甲骨文、金文），再到秦（小）篆汉隶，魏晋楷书，最后到今天的简体字，汉字已不再是单纯的工具，而演变成一种文化。

从繁体字到简体字，有许多简化规则。但归纳而言可分为两类，一是同形简化^【7】，再是同音简化。对于前者，简体字几乎把繁体字所剩无几的象形文化丧失殆尽；对于后者，则损害了汉字的字源文化，形成一字多源和多字一源的复杂局面。而两者共同作用，更使得大部分简体字已不再是形声字^【8】。

三、逻辑

对比繁体字，简体字逻辑上并不一致。许多繁体字中相同的部件被简化为不同的笔划^【9】，而相反，有些繁体字中不同的部件却被简化为相同的笔划^【10】。此外，还有多音字部分简化的问题^【11】。

四、美感

文字是一门艺术，属于美学范畴。

同样一幅书法，分别用简繁体字书写，繁体书法要略胜一筹。繁体字笔划众多结构繁复却又错落有致，给人强有力的视觉冲击，尽显方块字的艺术特质。需要说明的是，草书不在讨论之列，因为许多简体字原就取材于草书写法^【12】。

计算机显示恰恰相反。由于分辨率的原故，常见的汉字字体大多在 16×16 点阵附近。这对于清晰显示繁体字远为不够，更别提艺术字体。

综上，一己之见，简体字之于繁体字，正如白话文之于文言文，普通话之于地方话，皆不可废弃。汉字应当简化，这是顺应汉字删繁就简变曲为直的演化规律。同时，简体字的推行也不当以繁体字的没落为代价，应实行两套文字并行的方式：对于符合现代文体的语言现象，包括成语俗语，采用简体字表达；而对于不符合现代文体的语言现象，如诗词曲赋，文言篇章，古文引用等，则采用繁体字表达。这就要求国民教育至少应普及常见繁体字的认知识记，做到这点其实并不困难。

例注（专有名词以台译为例）

【1】灯（燈）；梦（夢），齐（齊）。

【2】发（出發，頭髮）；郁（憂鬱，浓郁）；饥（飢餓，饑荒）；台（檯燈，臺榭，颱風，台tāi州）。

【3】着（著想），著（著作）。

【4】达芬奇（達文西）；肯尼迪（甘迺迪）。

【5】克罗地亚（克羅埃西亞）；意大利（義大利）；悉尼（雪梨）。

【6】菜谱（食譜）；打印机（印表機）；互联网（網際網路）。

【7】龟（龜）；声（聲）；众（眾）。

【8】面（麵條，前面）；夸（誇）；头（頭）。

【9】登（登），灯（燈），邓（鄧）；幸（幸），报（報），泽（澤）；乡（鄉），响（響），飨（饗）；阳（陽），杨（楊）。

【10】云（雲），运（運），坛（論壇，罎罐），层（層）；结（結），洁（潔），桔（橘）；芊（芊），纤（纖細，縴繩），迁（遷）。

【11】干（乾湿），乾（乾坤）；了（瞭解），瞭（瞭望）；余（剩餘），馀（餘年无多）；雠（讎校），仇（讎恨）。

【12】书（書）；乐（樂）；为（為）。

游戏琐见

Fri, 13 May 2005 08:05:21 GMT

【分类】游戏 » 益智游戏 | 数学 » 算法复杂度

【标签】围棋 | 连珠 | 魔方 | 俄罗斯方块 | 扫雷 | 推箱子

天道之行，周而复始。所谓物极必反，盛极必衰，水满则溢，月满则亏；所谓大象无形，大音希声，大智若愚，大器晚成；所谓静以制动，柔以克刚，否极泰来，乐极生悲。

《易·系辞》曰：“易有太极，是生两仪，两仪生四象，四象生八卦。”天地万物繁衍生息总是始于简单的形式，经历一系列错杂繁复的变化，终至今日精彩纷呈的大千世界。

这里谈的是游戏，不是以动作情节见长的场景游戏，而是以博弈解题称道的思维游戏。

毋庸讳言，以易理论，古往今来最具深度的游戏当是围棋。围棋开盘之前，有如天地未分的混沌状态，清浊不辨，氤氲虚缈。待得引入黑白二子，阴阳至此分离，时空继之诞生。随着布局攻防死活之争，生克哲理暗藏其间，进而演化为波澜壮阔蔚然大观的庞驳局面。可以说，围棋内涵之深刻，外延之广博，呈现出东方文化独特的宏观视角，这与桥牌、象棋、连珠（五子棋）之类依傍严格推理和精确计算的西式游戏大相径庭。也正为此，寄望于现代数学和人工智能方法彻底解决围棋问题几无幸翼。此外不得不提及，所谓天残地缺，围棋的设计也非完美。且不论让人如芒在背的循环劫，作为对弈类游戏，围棋不可避免地存在先行优势的通病。现行的规则多采取局终贴目（子、点）进行抵偿，但终不免失衡。更重要的，这种补救有如刀削斧砍，大损自然造物之美。

先行优势的典型例子可数连珠，即便引入黑棋禁手（三三、四四、长连），廿六种星月开局中，黑优仍居大数。而进一步的平衡来自三手可交换和五手两打法——这种制约却似百纳衣的碎絮补丁，斑驳凌乱褴褛不堪。另外，升级（八十分）似乎也倾向庄家优势，碍于降低升级分值不甚妥当，取消底牌或许更显合理——这样做的额外好处是便于准确算牌。

言毕形而上的围棋，来瞧瞧形而下的魔方（Rubik's Cube）。魔方可谓是横空出世。面世之初，几乎无人相信自然界存在三轴六面均能自由旋转的机械实体。不仅如此，从规则到逻辑，从技巧到复杂度，三阶魔方无不显露着和谐浑成恰到好处。并且，有别于八数码（重排九宫）、华容道、独粒钻石及许多解题游戏，魔方的可解性不言自明。原因在于，尽管魔方看似困难，却存在多种通用的构造解法，而且无一例外不是中途点法。中途点法的思想是将难以解决的大问题分割为若干易于解决的阶段性目标，这种分割表现在时间上，而不同于分治法的空间分割。代价则与贪婪法相似，可能无法获得最优解。具体到魔方，一种可行的方法是：①完成底面；②完成底面邻行；③完成中行；④完成顶面十字；⑤完成顶面四角；⑥完成顶面邻行。各阶段操作相对独立，但后继目标的实现不能破坏之前既得的结果。这一过程可用群来描述。容易知道，魔方的方块分为心块、边块和角块，这三类方块互相不能交换，因此对应构成的置换群就有三个：心置换群、边置换群和角置换群。再者，边块的两面可以翻转，角块的三面可以旋转，因此边块自身又构成二阶循环群，角块则构成三阶循环群。这就是魔方求解的数学模型。当然，方法并非唯一。借助计算机，采用启发式搜索并选取良好的启发函数，往往可以获得最优或者近似最优解。

俄罗斯方块（Tetris）是另一款尽人皆知的游戏，其设计同样让人赞许。不知诸位可曾留意不同方块的形状、数目及其构造原理。不难发现，所有这些方块皆为 4 个单位面积，剔除旋转同形，4 个单位面积方块的枚举数为 7，这正是俄罗斯方块造型的全部。相较于三阶的枚举数 2 和五阶的枚举数 19，四阶无疑是最佳选择。更深一层，俄罗斯方块可归结为非周期平面镶嵌（Tessellation）问题——相信绝大多数俄罗斯方块程序随机地而不是依据当前局面和难度产生方块——属于非递归数学范畴。也许用俄罗斯方块讨论平面镶嵌显得小题大作，不妨设想，如果将方块换成 Raphael M. Robinson 六花砖，结果又将如何……

扫雷（Minesweeper）伴随着 Windows 的成长经久不衰，几经风雨，几易春秋，仍旧音容不改。这着实使人疑惑。虽说扫雷的构思几臻完美，但程序实现却非无懈可击。大凡入过此门之辈，恐怕没少经历正襟危坐却举步成灰的沮丧。果真难以修缮吗？结论恰恰相反，可说是举手之劳。解决方法不妨称为滞后布局，亦即将布局延至初次点击之后，从而轻易避开当前方格。更进一步，扫雷求解基于集合论和数理逻辑，核心思想是寻找相邻区域子集，其所有元素均可确定为雷或非雷。那么，是否存在一种布局算法，使得全局单元皆可推理无须猜测？遗憾的是，这份希望几已破灭，因为扫雷早被证明属于 NP 完全问题。

至此提及的游戏多少有迹可循，推箱子（Sokoban）却是不然。更甚于 Mummy Maze、Funny Ball 2000（非新版 2）、Clickomania，很难为推箱子总结技巧和规律，似乎也找不到其所对应的数学模型。精致巧妙的关卡全凭人为设计，求解过程不仅空间相关，而且时间相关，这些都暗示着游戏的复杂性。事实也是如此，推箱子已被证明属于 PSPACE 完全问题，即便求助于计算机，也只能得到局部结果。

形式简单，结构完备，脉络明晰，意蕴悠长。优秀的游戏之所以优秀，道理正在这里。

尽极繁复，归于简约；尽极简约，终至纯美。天运物器，人伦事理，尽皆如此。

剪燈閒筆: 剪裁边缘

双鱼 香草 咖啡（一）

关于汤姆孙灯问题的解释

哈泽德的难题

无处不在的相似

屏幕刻度尺

C# 和 Java 中不规范的隐式类型转换

天平分堆问题

朝花夕拾

英文文档中的中文乱码

数据共享与信息关联

标识符命名规则

实形有别

世界地理

麻将九听牌型

简繁之思

游戏琐见

双鱼香草咖啡（一）