上古：上海古籍出版社 2019 年二版第一次印刷；上海古籍出版社 1986 年版，2011 年 9 月第九次印刷

胡刻：https://www.shuge.org/ebook/wen-xuan/

尤刻：中華書局 1977 景國家圖書館藏尤刻本，再造善本

考異嘉慶刊本：https://www.shuge.org/ebook/wen-xuan/

錯字（文選及李善注）

錯字（考異部分）

版式錯誤

二三九（2019 本已更正，二三五），「文選異考」，當為「文選考異」

我離開去拿一個水壺，回來的時候看到妳，妳說要用這個桌子須要先輸入一個密碼。

我料想這還不簡單，因為她曾經告訴過我妳的密碼，作為曾經幫助過她們的回報。671531，妳搖了搖頭，密碼不對。

我疑惑地又想了一遍，不可能會錯的！啊，我恍然大悟，我只是記錯了一位數字而已，為什麼就不能再試一次。

我撇過頭看看她，她明明告訴過我密碼，她笑一笑，愛莫能助。

我打開妳的QQ群，我還在群裡面，她還是管理員。忽然群裡彈出了一個提示，她允許了一個新的詞語的使用。

我要離開這個地方，這樣我就不會感覺到我被妳拒絕了。

我提著行李站在走廊上，忽然發現妳和她也要離開。我錯愕不已，這讓我的離開變得沒有意義。

我知道這是我最後一次看見妳，我想如果我看著妳的時間比妳看見我長，那我就不會有遺憾。

妳看到了我在看妳。

足以讓我在十年後從夢裡驚醒過來。

Disclaimer: I am not a UC Berkeley student and I don’t have access to the hive machines. Although the project states that the code need to be run on a hive machine but there is no major obstacles debugging and running on a unix-like OS, i.e. macOS, as long as your CPU supports Haswell assembly instructions. The dataset on the hive machine is also public available: I download the CIFAR dataset and run the code on a Macbook Pro 2016.

Profiling

The project introduces some useful gprof commands for profiling. Unforturnately gprof is not supported on macOS, so I uses pprof instead, which can generate similar gprof-like flat profile.

1
2
3

$ cc -lm -lprofiler -Wall -Wpedantic -Wextra -march=haswell -std=c99 -fopenmp -O3 -o benchmark benchmark.o network.o layers.o volume.o
$ ./benchmark benchmark 1200 CPUPROFILE=/tmp/prof.out
$ pprof --top ./benchmark /tmp/prof.out

Here is an (incompleted) output example

1
2
3

 flat  flat%   sum%        cum   cum%
0.03s  0.51% 99.32%      0.03s  0.51%  _posix_madvise
0.01s  0.17% 99.49%      0.20s  3.42%  _load_batch

You should interpret the profile to find out which routine occupies most percents of running time.

A beard well lathered is half shaved.

The profiling command is used so often that I would recommend to write your own Makefile rule, i.e. make benchmark_profile from the very begining so that you can profile your program with minimum cognitive loads.

Common Techniques

Hoist memory operations

Hoise memory operations in nested loops if you know they are not changed inside the loop. For example,

1
2
3
4

for (int i = 0; i < 1 << 16; i++) {
    baz();
    foo->bar->quz[i] = i;
}

The compiler would not know whether foo->bar->quz points to the same memory location in the loops. Therefore it would generate three mov (lw in RISC-V) inside the loop. If you, Homo sapiens, know in advance that foo->bar->quz is a loop invariant, please explicitly convey the fact to the compiler by hoisting the memory operation.

1
2
3
4
5

int* quz = foo->bar->quz;
for (int i = 0; i < 1 << 16; i++) {
    baz();
    quz[i] = i;
}

There is a common misunderstanding that you should hoist everything you can. No! Any modern optimizer will hoist simple math operations for you, (but not memory operation since they are not semantically equivalent). For example you should not worry about whether you need to hoist j * j, the optimizer will do this automatically. Hoisting every simple math operation simply wastes your precious time.

1
2
3
4
5
6

int* quz = foo->bar->quz;
int j = 42;
for (int i = 0; i < 1 << 16; i++) {
    baz();
    quz[i] = i + j * j;
}

Eliminate branches

Scrutinize the branch operations in deeply nested loops, especially those conditions related to the loop counter only. You can replace branch by carefully chosen counter ranges.

1
2
3
4
5

for (int i = 0; i < 1 << 16; i++) {
    if (i >= m && i < n) {
        /* do something on i */
    }
}

In the example above, we can get rid of the if branch by having i loop from min(0, m) to max(1<<16, n).

Minimize number of variables involved in deep loops

Use your Math skills to minimize the variables inside deep loops. For example, let’s say you have a 8-register CPU runing the following code

1
2
3
4
5
6
7
8
9
10

loop1:
for (int i = 0; i < 1 << 16; i++) {
    /* do something with j, k, l, m, p */
    q = m * k;
    loop2:
    for (int n = 0; n < 1 << 16; n++) {
        quz = (n + m) * k 
    }
    /* do something with j, k, l, m, p, q */
}

Before jumping to loop2 with four variables involved, the compiler have to put at lease one register used in the loop1 onto the stack, and restore after loop2 is finished. This process is called register allocation.

Apparently quz = (n + m) * k can be simplified to quz += k if one initializes quz = q.

1
2
3
4
5
6
7

for (int i = 0; i < 1 << 16; i++) {
    /* do something with j, k, l, m, p */
    q = m * k;
    loop2:
    for (int n = 0, quz = q; n < 1 << 16; n++, quz += k) { }
    /* do something with j, k, l, m, p, q */
}

In the latter cases loop2 still has 4 variables (n, quz, k, q), but since q is reused, we don’t have to save anything on the stack,which means, let’s say p is in %rbx you have saved 65536 push %rbx and 65536 pop %rbx instructions.

As a byproduct you have also reduced the computation strength of (n + m) * k to quz + k, but the bottleneck here is mov since the latency difference of addition (0.5) and multiplication (1.75) is smaller than L1 Cache latency (3).

Inline small static functions, copy & paste if compiler doesn’t

Function with many arguments will incur spill and reload register pressure, which means you will have much more mov in the prologue and epilogue of the called function. You may know that in C we could declare that a function is inline so the compiler will try to merge the intructions of this function to wherever it is called. But any modern optimizier will automatically inline small functions even if you don’t specify it is inline.

1
2
3
4
5
6
7
8
9
10
11

#include "helpers.h"

/* will be automatically inline in most cases */
static int foo(int x) { return x + 1; }

int main() {
    foo(0);
    /* would not be inline if bar is defined in helpers.h */
    bar();
    return foo(0);
}

However, there are some exception cases where the compiler could not inline the source. For example, if a small function is defined in other headers, the compiler would not inline this function since it is in another object file. But we know it is small and static, so we can simply copy paste these functions so that our critical parts will execute an inline version of these small helpers. By doing this we can get rid of the function overhead: extra spills and reloading stack memory access.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#include "helpers.h"

/* copy pasted from helpers.h */
static int bar(int x) { return x + 2; }

/* will be automatically inline in most cases */
static int foo(int x) { return x + 1; }

int main() {
    foo(0);
    /* would be inline since bar is defined in same object file */
    bar();
    return foo(0);
}

You may have a sense now our performance optimization actually focus on the number of memory operations. And yes visiting memory/cache is way slower than computation. The more mov you have reduced, the more performance gain you get.

OpenMP

Although the OpenMP section is in the last. Personally I recommend to apply OpenMP in the earlier stage as long as you figure out where to add OpenMP pragmas. It should be added to the biggest parallelable computation units with minimum input variables. Once you have correctly configured OpenMP, you will have an independently 5-6x boost on a 4-core 8-threads machines. Combining OpenMP with the common techniques will give you 12x boost.

If you are running project on macOS like me, you may be teriffied by the fact that every partest fails on macOS. Note that partest simply tests your program against a rand() indexed of datasets (code), and macOS has different rand() implementation to Linux. So you have to generate the partest output from reference implementation yourself.

I have tried different OpenMP schedulers but they don’t differ a lot. I think we’d better keep it simple.

Unrolling

A modern optimizer will do loop unrolling for you so you don’t have to unroll if you don’t have a good reason, that is, you know nothing more than the compiler. I will mentioned unrolling later.

Specialization

Before talking about SIMD instructions, I would like to shred on specialization. A way that you convery extra information to the compiler. Let’s say if the critical part is vector operator: dot product, the compiler would not know the length of the vector, but you can always print at runtime to see if it reveals any pattern. After I reach 12x, I have been stuck for a while. It is a break through when I notice that the length of vector is actually discrete. I added a switch case to delegate dotProduct to different versions: 3x3, 16x16 and 20x20. The specializaed dotProducts get rid of the deepest for loop and we don’t need allocate register to the loop counter now.

SIMD instructions or Assembly Programmer

Hotpath

Both SIMD version of 16x16 and 20x20 dot product are straighforward to implement, for 3x3 dot product I leave is as-is because I don’t find any significant speed improvement. The SIMD version of 16x16 and 20x20 will boost performance upto 16x. You may relax since then, actually some students stop here according to the search result of github.

But if you want to beat the staff like what I did, it is only the begining. It is extremely important to profile how often or the percentage of time spend on dotProduct3_3, dotProduct16_16 and dotProduct20_20. You may find that the helper function dotProduct16_16 is inlined in -O3 but we can use directive to tell the compiler do not inline these functions.

1
2

__attribute__((noinline))
static void dotProduct3_3(double * dst, const double * dp_x, const double * dp_y)

Now you can see the benchmark

1
2
3

0.35s  8.86% 64.05%      0.35s  8.86%  _dotProduct16_16
0.25s  6.33% 70.38%      0.25s  6.33%  _dotProduct3_3
0.08s  2.03% 93.42%      0.08s  2.03%  _dotProduct20_20

Apparently, dotProduct16_16 and dotProduct3_3 is the hot path.

Devtools: Make a profiler switch

Note that you would soon find it cumbersome to switch __attribute__((noinline)) back and forth, thanks to C preprocessor we can define a __MODIFIER__ macro

1
2
3
4
5
6
7
8

#ifdef _PROFILE_
#define __MODIFIER__ __attribute__((noinline))
#else
#define __MODIFIER__
#endif

__MODIFIER__
static void dotProduct3_3(double * dst, const double * dp_x, const double * dp_y)

and create a profile-switch.h which simply define the _PROFILE_ macro

1

#define _PROFILE_

Then you can include profile-switch.h only when it is profiled.

1
2
3
4
5
6
7
8
9
10
11

CC=/usr/local/opt/llvm/bin/clang
CFLAGS?=-Wall -Wpedantic -Wextra -march=haswell -std=c99 -fopenmp -O3
PROFILE_CFLAGS=-lprofiler -Wall -Wpedantic -Wextra -march=haswell -std=c99 -fopenmp -O3

benchmark_profile : benchmark.o network.o layers.o_profile volume.o
    $(CC) $(PROFILE_CFLAGS) -o benchmark benchmark.o network.o layers.o volume.o -lm
CPUPROFILE=/tmp/prof.out ./benchmark benchmark
pprof --top ./benchmark /tmp/prof.out

layers.o_profile : layers.c layers.h volume.h
$(CC) $(CFLAGS) -include profile-switch.h -c layers.c -o layers_profile.o

Destroy small loops

I have mentioned that a SIMD version of dotProduct3_3 does not significantly improve performance. Let’s analyse it a bit. In dotProduct3_3 we will do two vmovupd (_mm256_loadu_pd) to load 4 64bit-memory cells, interpreted as double, into two YMM registers. But we are only computing a 3x3 dot product: we wasted 1/4 of the memory bandwidth!

If you take a closer look to the dotProduct3_3 loop, you will find the memory access location is continuous, i.e.

1
2
3

dotProduct3_3(dst, a[0], b[0]);
dotProduct3_3(dst, a[3], b[3]);
dotProduct3_3(dst, a[6], b[6]);

which means a loop of five dotProduct3_3 operation is equivalent to a dotProduct15_15 operation.

By checking the runtime states we can find that the loop bound is discrete, too. Profiling reveals that dotProduct15_15 is the new hot path. We can estimate that a dotProduct15_15 is 25% faster than 5 consequent dotProduct3_3. Why? Because we just need 8 vmovupd for dotProduct15_15, which is bounded by dotProduct16_16.

1
2
3
4
5
6

__m256d x_tail = _mm256_loadu_pd(x[11]); // x[14], x[13], x[12], x[11]

x_tail = _mm256_blend_pd(x_tail, _mm256_zero_pd(), 0x1); // x[14], x[13], x[12], 0

_mm256_mul_pd(x_tail, _mm256_loadu_pd(y[11]);
// returns x[14] * y[14], x[13] * y[13], x[12] * y[12], 0

In a way it is also a kind of unrolling with one loop only, but we have done more than that and reduces the number of vmovupd.

Some extra questions to think about: Do we need rewrite three dotProduct3_3 to dotProduct9_9? Do we need rewrite three dotProduct16_16? How about dotProduct20_20?

This change brings me 22x boost on Aug. 9.

Unrolling or abusing the precompiler?

The next thing I tried is unrolling the dotProduct16_16. Note that rewriting dotProduct16_16 to larger dotProduct does not benefit a lot since we can not decrease the number of vmovupd, it is optimal. But we can still get rid of loop by unrolling. The dotProduct16_16 is inside of number 3/4/5 loops. I ended up writing a macro which simply expands to a for loop with fixed bound. It is like

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

#define dotProductRoutine16_16(Round) {\
  for(int i = 0; i < Round; i++) {\
    dotProduct16_16(dotProductSum, a[/* index from i */], b[/* index from i */]);\
  }\
}

switch(round) {
    case 5:
        dotProductRoutine16_16(5);
        break;
    case 4:
        dotProductRoutine16_16(4);
        break;
    default:
        dotProductRoutine16_16(3);
        break;
}

The compiler does a good job optimizing those fixed loops and I have got 25x. But I knew from the comments that our staff has come up with a 27x in hand. So I should definitely do more to get extra credits.

Memory access

For the convenience of writing organization, I have placed memory access in an indepedent section. Actually I keeps thinking if there is anything I can improve on general memory access pattern other than the convolution step. It turns out there are several aspects you can look into:

• Try to print out the assignment values after a big malloc, if it is always zero, consider switch to hardware-friendly calloc. In macOS the compiler generates a special __platform_bzero$VARIANT$Haswell call which is way faster than accessing the memory and write only zero back. Yes we are still decreasing the number of mov.
• If sometimes the assignment is zero and sometimes not, consider switch to a memset and write to the memory only when it is not zero.
• Are there any loop pattern results to a high cache miss rate? For example are there any write steps where a whole cache line is loaded but only written one value? Consider to modify loop levels to leverage CPU caches.

All these efforts pay off: It brings me to 29.968x in Aug. 12

Performance Reports on my local machines

Flat profile of classifying 1200 images

1
2
3
4
5
6
7
8
9
10
11
12
13

 flat  flat%   sum%        cum   cum%
1.15s 64.97% 64.97%      1.16s 65.54%  _conv_forward
0.22s 12.43% 77.40%      0.22s 12.43%  __platform_bzero$VARIANT$Haswell
0.19s 10.73% 88.14%      0.19s 10.73%  _swtch_pri
0.07s  3.95% 92.09%      1.43s 80.79%  [libomp.dylib]
0.04s  2.26% 94.35%      0.04s  2.26%  _posix_madvise
0.03s  1.69% 96.05%      0.03s  1.69%  _read$NOCANCEL
0.02s  1.13% 97.18%      0.02s  1.13%  _pool_forward
0.01s  0.56% 97.74%         1s 56.50%  _.omp_outlined.
0.01s  0.56% 98.31%      0.01s  0.56%  __kernelrpc_mach_vm_deallocate_trap
0.01s  0.56% 98.87%      0.04s  2.26%  _free_small
0.01s  0.56% 99.44%      0.01s  0.56%  _lseek
0.01s  0.56%   100%      0.01s  0.56%  _relu_forward

The other forward operation has been optimized for memory access. _conv_forward, __platform_bzero$VARIANT$Haswell(zero-filling the memory), _swtch_pri(macOS libsystem_kernel calls) are the top-3 computing intensive calls.

Comparison to baseline: classifying 2400 images

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

./benchmark benchmark 2400
RUNNING BENCHMARK ON 2400 PICTURES...
Making network...
Loading batches...
Loading input batch 0...
Running classification...
79.083333% accuracy
820224 microseconds
./benchmark_baseline benchmark 2400
RUNNING BENCHMARK ON 2400 PICTURES...
Making network...
Loading batches...
Loading input batch 0...
Running classification...
79.083333% accuracy
36103328 microseconds

When comparing more than 1200 images, the thread overhead is ammortized and we could get a better speed up to 40x.

Summary

Performance programming is like collaborating with the compiler: you want to feed more facts into compiler so that it can help you get rid of superfluous memory operations. I learned C ten years ago and only in this project, and the other projects in CS-61C that I feel connections with this so called stone-age language. Its great flexibility and straight-forward memory layout enable various way to utilize the hidden power inside our hardware.

A beard well lathered is half shaved. Always spend some time on your development tools: scaffolds, mnemonics, command + R… Switching context not only gives your brain a break but also keep the fire burning so that you will not be blamed by yourself: I ended up doing no commits in a whole day!

CS 61C is the first course that I have spent so much efforts after I was graduated. I can’t believe I could finish all the projects and homeworks without access to TA and hive machines. It has inspired me a lot and proved to myself my learning abilities. Thank you CS 61C staffs for offering me such a great course and intriguing projects. Thank you my friend Wèi Cōngruì for dicussions on memory layout issues. Thank you University of Waterloo for offering a working environment to a new immigrant like me, for free.

现场签到

从 Clark/Lake 地铁口出来，沿着湖街直走，登上 AON 中心的空中走廊，穿过哥伦比亚大道。两边行人的衣服色调渐趋两极，非蓝即绿。但所有人都步履缓慢，他们的眼睛锁着挂上了充电宝的屏幕，他们的手指机械地飞舞着。我眼前一黑，抬起头，一辆黑色大巴拦住了我。

就是这辆贴着 NL-1331 的面包车，附带一个名为#NL133X 的 portal。NL-1331 的官方介绍如下：

NL-1331 features casual missions aiming to explore different cities and locales using a special Ingress-customized vehicle called the “XM Detection Mobile Lab.”

NL-1331 就是一个叫做 XM 检测仪移动实验室的到处跑的 po，上面还有非常随便的只有一个 portal 的任务。从车牌号可以看出来，这是从加州总部运过来的小车。

顺手摸了两个 key 以后，正好前面一个 PLMM 问一个小伙子：

「Where is the registration portal?」

「注册 po 就在大堂里面。」

进酒店之后一道紫光闪过，这就是注册的地方了。

注册完后会拿到了 Abaddon Prime 的小信封，看起来和高雄、阿姆斯特丹前两场的信封没有任何区别。

会场还有 Ingress Animation 的主角留影板

但是注册 po 才是签到的坑点

进去大堂 50 米，手机信号彻底没有。出来大堂之后，有信号定位已经不对了，沿着硕大的酒店大楼绕了一圈，依旧碰不到注册 po。最终转了两圈之后，找到了北蓝「小伙子」@BGDajiu，放了一个 Wi-Fi 热点，终于 hack 了注册 po，拿到 media。立马打 Uber 前往我们鹰队负责的 D 战区。

D 战区：大战前的控毒

Anormaly Map 应用提供了芝加哥战区地图，给每个 po 分了区域和编号，方便指挥。下图就是 D 战区的位置。

到集合地点的时候已经是 11:58，队长指示 12:00 把 D14 翻绿。一路小跑终于在 12:00 赶到 D14，却发现毒还在桶里，于是哆哆嗦嗦从桶里掏出了陈年绿毒，翻绿了之后在备忘录记下了时间，12:01。

事后看来，毒的时间需要十分精准的记录，精确到秒是必须的。否则当毒的免疫时期过了再次翻毒的时候，就会算不准免疫时间而使得毒被浪费掉。毒完回到集合点的时候，大家开始了愉快的 Pokemon Go 加好友交换 Pokemon 活动。我和 @Ma1aKai 换了一个 Pokemon Go 社区活动出来的 Unknown，显摆一下。

12:45 的时候，D 战区已经被蓝军全部打蓝，准备13:00的翻毒。毒完之后我们趁着半个小时的空闲时间，赶紧去吃一顿午饭。

在吃饭的同时，我也在 Prime 上注意到绿军在 D 战区已经开始连起来做 field 了。我问队长这是否是某种策略，队长说没什么这就是 xjbl。事后看来，绿军已经使用了 Carrie’s journal 提前获得了 Anormaly 第一个测量点的 research portal，而这其中就有 D区的 D22 po。1点多绿军连起来这些线就是把 D22 保护起来，以便在开赛前可以全部清掉，让其它 po 在第一个测量点之前可以连到 D22。

超新星的形成：碎片战

吃完饭后，蓝军绿军都开始聚集到 D22 po，大家都知道这里开战后会有事情发生。同时，绿军也开始从各个方向连到 D22，当时的场面是这样的：

大战开始后，这里果不其然成为了绿军的研究 portal（会有一个黄色的小三角形）

许多碎片也开始被传到这个球门。

而在此后的一个小时，D战区一直被绿军统治，贴个图体会一下啥叫绝望。

15:30 鹰队退出 D 战区，后勤大姐的 food cart 准时停在路边，各位特工蜂拥而至。

零食、水、急救包一应俱全。

一番补给之后，我们上了一辆神秘的大巴。

UPH——移动的摸 po 机

此前我在必输的 XMA 体验注定很差？一文中得知凤凰城 XMA 是有 SUV 负责 UPH 之旅，所以对有专车负责 UPH 这事不出奇，但大巴都动用了还是让我觉得非常意外，蓝军果真是大投入啊。

于是我们坐着大巴，听着 ADA，吹着空调，喝着冰水，一路 hack。我刚上车的时候还不知道这是一个秘密行动，放了一些多余的八炸清仓，被后面的大哥「Don’t Attack」喝止了。一路上收集着 Artifacts Portal 掉落的 Media。

大巴策略让蓝军的 Artifacts 数量和 UPH 都超过了绿军。深蓝 @CrytoGL 评论得好：「现在人数或者战斗力劣势方都是这么玩了，战术另寻蹊跷」。

最后也要顽强

坐了二十分钟的车后我们下了车，距离结束还有一个多小时一点的时间，队长建议把 S16 毒绿，这样可以在最后一个测量点之前全部毒蓝。但我们发现 S16 上面还挂着碎片，决定驻守 S16，事实上这是鹰队在整场 XMA 唯一的贡献。S16 在下一个测量点变成了 research portal，蓝队成功进了几个球。在这期间还要和 GPS 对抗，实在不容易。但纵观全场，我们队里没有划分角色，大家打 portal 都是各打各的，如果组织再好一些，有人放炸、有人放盾、有人放脚，最后的战斗力会更强一些吧？

在最后一个测量点到来之前，我还离队占了一个更远处的 po，一时手抖 A 盾上成了 VRSB，截图留念，战斗到最后一刻，8 脚全都用光了。

After Party

在 After Party 中，最惊喜一刻莫过于 Hank 宣布抵抗军取得了 XMA 的胜利，从而取得 Oasis 系列赛的最终胜利，毕竟在地面战和碎片战中一直被绿军碾压。

回想自己年初才入坑（成为 Ingress 玩家），承蒙深蓝社团帮助，稀里糊涂参加了马尼拉奎松市的充电房，拿到了 Darsana Prime 的贡献章，加上今天的 Abaddon，算是参与了两个赛季。

鸣谢

• 感谢 @BGDajiu 开放的 Wi-Fi 热点
• 感谢 @Ma1aKai 赠予的 70 个 VR 盾和 88 个 AXA 盾
• 感谢各位读者读到这里，后会有期

莫名其妙住进 522 房间的一号上铺以后，我买来下学期的化学教辅，一边配平化学方程式扫描任何没见过的分子式，一边在大脑里随机组合此起彼伏的名词与动词。十一月以后，大陆风渐渐盛行，干燥的天气让太阳光变得平易近人。诺大的操场跑着我丝毫不感兴趣的校运会，但是也因此有机会，能在太阳下，低着头听铅笔写在《数独 5》上喳喳的声音。

首先想到的是维护一个 9×9×9 的候选组，前两维是位置，后面是每个方格能填哪些候选值。第一次先扫描整个数独，同行、同列、同方块这个三个约束可以让候选组缩小，如果发现了哪个候选组长度是1，那就说明已经通过排除法确定这个元素是什么。这个时候填入这个元素，同时更新与这个元素同列、同行、同方块的候选值，然后接着找长度是 1 的候选组。这样就又回到之前的状态。

横竖的约束就像中国象棋里的車，每一个数字都能把同行同列杀得片甲不留，而那团团的九宫格里空位有时候本就不多，几趟車开下来，躲起来的数字就没地方跑了。新的数字又是新的車，奔向新的远方。侧过头看看X君，淡绿色制服，短发及肩。广播里单曲循环着已经是第47个年头的《运动员进行曲》，又被体育教头的「请某某、某某某同学到主席台前面……」打断，再被裁判的「预备……跑！」打断，再被班主任的「大家不要光在这里坐着……」打断，直到心里说：「这个地方要填3。」

候选组的思路和从前我做数独很相似，但我也知道有些标记成困难的题目实在找不到只有一个候选值的情况，这个时候就只能挨个去试验，也是非常苦恼且容易出错的一过程。回到刚才的算法，我们并不能断言每次总能运气这么好找到长度为1的候选组，所以需要教会计算机，或者是教会自己，如果最短候选组的长度大于1，应该怎么做。

应该怎么做呢？每个用来填数字的方格有四个顶点，于是我可以用铅笔在方格的四个角落里用八号字体的蝇头小楷注上候选值，然后照着假设接着去做就好了。实在运气不好要推翻一堆数字的时候，那就拿个简单难度的数独来撒气吧。话是这么说，我看到只做了一半的数独，心中总是充满了挫败感。

可是编程就是不停地和自己的挫败感打架。你可以想象在 Visual Studio 2008 里面给一个几百行的 main 函数设置断点一步一步点击跳转监控整个状态集么？这个没有类型、没有内存安全的语言让调试过程充满了各种各样的惊喜。从来没有测试驱动的理念，大学里的编程教育也和现实工程脱节太远，于是验证算法的正确性的唯一方式就变成了人类本能——看 log。在晚上十一点半以后，我终于把笨拙的加法计算器写出来。程序输出结果的那一刻，我没有想到十年后的自己在书写着数独求解器的测试用例。既然对候选组长度大于1的情形没有思路，那不如先把测试写了吧。

偶尔翻到一页有X君的笔迹，心中的一秒钟欢喜给下一分钟的波澜不惊做好了铺垫，还是不叨扰她的未完成吧。快到中学的时候爸妈给我买了一本三十九块钱的接力出版社出版的《彩图袖珍自然百科》，全彩铜版纸印刷的三十二开本，讽刺的是每天睡觉前我都喜欢把书拿到床头，然后就这么放在边桌上，看书页边缘溢出来的一点点彩色油墨，每16页叠成一个书帖，30多个书帖沿着锁线的方向起伏，这些头发丝里的般点也竟铺成了一窗夜空。我惊讶于这本书的精致，尽管只是普通的精装书而已，而只愿我永不打开这书，也就永远能看到它最完美的样子了。也正如彼时一样，这一页未完成也因X君而带上了无瑕，如果要让它停在最完美的时刻，最好的便是逃跑一般地翻到下一页。

撇开实现看测试，书写测试本身是直接的。原问题使用[][]byte来建模一个数独，每个 byte 取1到9这九个 ASCII 字符作为数字1到9，取.作为空白的方格。SolveSudoku本身修改这个二维切片引用的数据，修改完后再取这个切片把数据打印出来就可以了。测试数据为了人类输入方便，是一个换行分割的字符串，最终打印出来的也是这样的格式。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

func ExampleSolveSudoku() {
sudoku :=
`
53..7....
6..195...
.98....6.
8...6...3
4..8.3..1
7...2...6
.6....28.
...419..5
....8..79
`
board := stringToBoard(sudoku)
SolveSudoku(board)
result := BoardToString(board)
fmt.Println(result)
// Output:
// 534678912
// 672195348
// 198342567
// 859761423
// 426853791
// 713924856
// 961537284
// 287419635
// 345286179
}

不管是横竖的约束，还是九宫格的约束，人做数独的喜悦都在于搜索所有条件并寄希望于能靠运气碰到一个靠约束可以唯一确定的空格。明白这个问题本质上是在潜在解空间中寻找一个解，那么对计算机来说，它不需要像人类这么左顾右盼找运气，它只需要踏踏实实从第一个空开始尝试就可以了。寻找到第一个空格的地方，从1试到9，如果没有冲突，再继续尝试下一个数字。它不必焦虑于从1尝试到9是不是显得很蠢。这个空格左边就是一个1，怎么可能从1开始试呢？但本质而言，填了1被左边的1否决掉，和填了2，9，3 才发现第 3 个空格里的 3 不满足约束，从而必须尝试下一个 294 的解这两件事情对计算机来说毫无区别，如果第一个1就被否决掉，那么就从下一个解开始继续试。1的下一个是2， 293的下一个是 294，无论长短，无论是填了一个就被否掉，抑或是填完了快一半的空格才沮丧地发现要推倒重来，计算机没有情绪起伏，它不因「似乎可以直接否定某个候选值」而开心，也不因「为什么做了一半才发现整个假设从头开始就错了」而难过。它简单而愚蠢，但这个方法却因为它可以在初期就排除掉很多不可能的解而在实际运算中经常非常高效。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

func bt(solution PartialSolution) *PartialSolution {
if reject(solution) {
return nil
}
if accept(solution) {
return &solution
}

for s := first(solution); s != nil; {
result := bt(*s)
if result != nil {
return result
}
s = next(*s)
}

return nil
}

剩下就只需要按照数独的规则实现 reject, accept, first, next 这几个函数就可以了。

印象中bt更多是变态的拼音首字母缩写和 BitTorrent 的大写字母缩写。「变态」这个词一方面来源于对生物学上的 metamorphosis 的翻译，另一方面却又因为日本人率先把 Sexual Perversion 翻译成「変態性欲」而又传回中国被大家意指「怪胎」或是「色狼」。一个词带上了色情意味就总会让含蓄的中国人想办法去避讳，避讳的结果就是新创出行话以显示自己在社会活得长了，也是见过世面的。于是从「傻屄」到「傻逼」到「傻B」到「sb」，侮辱意味的名词不断地吞噬同音字、拼音缩写词，最后以至于「jb」的原字「𣬠𣬶」竟然只能放在 CJK 表意文字扩展 B 区了，而近于无人知晓了。也罢，这些奇怪的□□不都是叫做「乱码」了。有了这顶帽子，也就不必追寻本来的意味了。

这个时候已经有了计算机批量生成的数独，编者要在前言中注明这些数独都是人精心构造出来的。与机器生成的不同，这些数独会有着独特的美感，例如某几个数字的对称性，数独的提示只有固定的两三个数字，其实就是计算机算出来的数独再加上一些审美的价值判断。但多巴胺总会激励你继续往前做，翻过一座又一座的山，直到频次降低，漫长而不经意地把这个习惯丢失。但人不甘心从有到无的过程变化得那么缓慢，而总愿意安排一个模糊而又实质的时间——「在那一刻，我不再做数独了。」——显得改变总是一瞬间，千丝万缕，斩不断理还乱，而不愿明说这一刻的 Unix 纪元。

只要十一点过后是九点半，地球又往西摆动了 22.5°，二年级的体育生又一次打破了年级记录，运动员进行曲又提前了80秒，《数独 5》又往前翻八页（不想说还有六页是X君的未完成），X君始终低着头，看不清楚颜面。那么永恒，就是这样一个回圈。

而我不愿意就这样草草收场。如果说 for { } 就是一个最简单的回环，什么事情也不做，来回地困在当下。我更愿意回圈是一个生成器，一个取票机的工厂：

1
2
3
4
5
6
7

function *fibonacci(current = BigInt(0), next = BigInt(1)) {
  yield current;
  yield *fibonacci(next, current + next);
}
const ticket = fibonacci();
ticket.next();

每次都能通过ticket.next(ticket.value)取出一张新的船票。永远在沉睡，永远不结束，永远在等待下一次计算；但没有不确定性，没有噪音，没有抬头，没有句号。

110 纳秒以后，它输出了这个数独的解。

一个可能有 20 年历史的正则表达式

在谷歌搜索「JavaScript 正则表达式匹配汉字」的时候，前几条结果全都是/[\u4e00-\u9fa5]/。没有人怀疑这个正则表达式有什么问题，那么在 2018 年的今天，让我们站在 Chrome 64 的肩膀上，放飞一下自我。

汉文（Han Script）是汉语、日本语、朝鲜语、韩国语的书写系统中的一种文字（Script），越南语在早期也曾在书写系统中使用汉文¹。汉字（CJK Ideograph）是汉文的基本单元。汉字文化圈中的许多国家或地区都对汉字提出了自己的编码标准，Unicode 将这些标准加总在一起进行统一编码，力求实现原标准与 Unicode 编码之间的无损转换。Unicode 从语义（semantic）、抽象字形（abstract shape），具体字形（typeface）三个维度²出发，把不同编码标准里「起源相同、本义相同、形状一样或稍异」的汉字赋予相同编码，这些被编码的字符称为中日韩统一表意文字（下文我们提到的「汉字」，如果不加说明，均指代中日韩统一表意文字）。如果把它们全部列举出来写成正则表达式，那么就是技术上完整的匹配汉字的正则表达式了。

正则表达式/[\u4e00-\u9fa5]/的意思是匹配所有从 U+4E00, cjk unified ideograph-4e00 到 U+9FA5, cjk unified ideograph-9fa5 的字符。这一段区域对应的是 Unicode 1.0.1 就收录进来的中日韩统一表意文字（CJK Unified Ideographs）区块，在 Unicode 3.0 加入表意文字扩展 A 区块以前，这个正则表达式确实给出了所有汉字的编码。换言之，从1992年到1999年，这个正则表达式确实是正确的。这么看来，想必这个表达式已经有20年历史了。

匹配所有统一表意文字

然而时光飞逝，Unicode 在2017年6月发布了10.0.0版本。在这20年间，Unicode 添加了许多汉字。比如 Unicode 8.0 添加的 109 号化学元素名称「鿏（⿰⻐麦）」，其码点是 9FCF，就不在这个正则表达式范围中。如果我们期望程序里的/[\u4e00-\u9fa5]/可以与时俱进匹配最新的 Unicode 标准，显然是不现实的事情。因此，我们需要换一个思路，写一个无需维护的正则表达式：

1

/\p{Unified_Ideograph}/u

其中\u是 ECMAScript 2015 定义的正则表达式标志，意味着将表达式作为 Unicode 码点序列。\p{}是 ECMAScript 2018 定义的正则表达式 Unicode 属性转义，它向开发者提供了根据 Unicode 字符的属性数据³构造正则表达式的能力。Unified_Ideograph是 Unicode
字符的一个二值属性，对于汉字，其取值为 Yes，否则为 No。因此\p{Unified_Ideograph}匹配所有满足Unified_Ideograph=yes的 Unicode 字符，而它的底层实现由运行时所依赖的 Unicode 版本决定，开发者不需要知道汉字的具体 Unicode 码点范围。

容易混淆的其他 Unicode 属性转义表达式

/\p{Ideographic}/u

这个表达式匹配所有满足Ideographic=yes的 Unicode 字符。它是Unified_Ideograph=yes的超集。我们先看一下 UAX #44 对这个属性的解释⁴：

Characters considered to be CJKV (Chinese, Japanese, Korean, and Vietnamese) or other siniform (Chinese writing-related) ideographs. This property roughly defines the class of “Chinese characters” and does not include characters of other logographic scripts such as Cuneiform or Egyptian Hieroglyphs.

这个属性表明该字符属于 CJKV 表意文字或者与汉语书写相关的其他表意文字（如西夏文、女书），这个属性粗略地定义了「中文字符」的分类。我们查看Unicode 10.0.0 字符属性列表可以知道，在 Unicode 10.0.0 中，

3006          ; Ideographic # Lo       IDEOGRAPHIC CLOSING MARK3007          ; Ideographic # Nl       IDEOGRAPHIC NUMBER ZERO3021..3029    ; Ideographic # Nl   [9] HANGZHOU NUMERAL ONE..HANGZHOU NUMERAL NINE3038..303A    ; Ideographic # Nl   [3] HANGZHOU NUMERAL TEN..HANGZHOU NUMERAL THIRTY3400..4DB5    ; Ideographic # Lo [6582] CJK UNIFIED IDEOGRAPH-3400..CJK UNIFIED IDEOGRAPH-4DB54E00..9FEA    ; Ideographic # Lo [20971] CJK UNIFIED IDEOGRAPH-4E00..CJK UNIFIED IDEOGRAPH-9FEAF900..FA6D    ; Ideographic # Lo [366] CJK COMPATIBILITY IDEOGRAPH-F900..CJK COMPATIBILITY IDEOGRAPH-FA6DFA70..FAD9    ; Ideographic # Lo [106] CJK COMPATIBILITY IDEOGRAPH-FA70..CJK COMPATIBILITY IDEOGRAPH-FAD917000..187EC  ; Ideographic # Lo [6125] TANGUT IDEOGRAPH-17000..TANGUT IDEOGRAPH-187EC18800..18AF2  ; Ideographic # Lo [755] TANGUT COMPONENT-001..TANGUT COMPONENT-7551B170..1B2FB  ; Ideographic # Lo [396] NUSHU CHARACTER-1B170..NUSHU CHARACTER-1B2FB20000..2A6D6  ; Ideographic # Lo [42711] CJK UNIFIED IDEOGRAPH-20000..CJK UNIFIED IDEOGRAPH-2A6D62A700..2B734  ; Ideographic # Lo [4149] CJK UNIFIED IDEOGRAPH-2A700..CJK UNIFIED IDEOGRAPH-2B7342B740..2B81D  ; Ideographic # Lo [222] CJK UNIFIED IDEOGRAPH-2B740..CJK UNIFIED IDEOGRAPH-2B81D2B820..2CEA1  ; Ideographic # Lo [5762] CJK UNIFIED IDEOGRAPH-2B820..CJK UNIFIED IDEOGRAPH-2CEA12CEB0..2EBE0  ; Ideographic # Lo [7473] CJK UNIFIED IDEOGRAPH-2CEB0..CJK UNIFIED IDEOGRAPH-2EBE02F800..2FA1D  ; Ideographic # Lo [542] CJK COMPATIBILITY IDEOGRAPH-2F800..CJK COMPATIBILITY IDEOGRAPH-2FA1D# Total code points: 96174

囊括了所有统一表意文字、西夏文及其组件、女书、中日韩兼容性字符、苏州码子、「〇」以及日本语中的书信结尾标志「〆」。使用/\p{Ideographic}/u来匹配汉字会过于宽泛。一是包含了西夏文、女书，二是只用于编码转换用的兼容字符也纳入其中。

/\p{Script=Han}/u

Script 属性⁵用来筛选满足下面条件的一组字符：

1. 字符的书写形式具有共同的图像特征与文字流变
2. 该组字符全部用来表达某个书写系统内的文本信息（textual information）

我们查看Unicode 10.0.0 Scripts可以知道，

2E80..2E99    ; Han # So  [26] CJK RADICAL REPEAT..CJK RADICAL RAP2E9B..2EF3    ; Han # So  [89] CJK RADICAL CHOKE..CJK RADICAL C-SIMPLIFIED TURTLE2F00..2FD5    ; Han # So [214] KANGXI RADICAL ONE..KANGXI RADICAL FLUTE3005          ; Han # Lm       IDEOGRAPHIC ITERATION MARK3007          ; Han # Nl       IDEOGRAPHIC NUMBER ZERO3021..3029    ; Han # Nl   [9] HANGZHOU NUMERAL ONE..HANGZHOU NUMERAL NINE3038..303A    ; Han # Nl   [3] HANGZHOU NUMERAL TEN..HANGZHOU NUMERAL THIRTY303B          ; Han # Lm       VERTICAL IDEOGRAPHIC ITERATION MARK3400..4DB5    ; Han # Lo [6582] CJK UNIFIED IDEOGRAPH-3400..CJK UNIFIED IDEOGRAPH-4DB54E00..9FEA    ; Han # Lo [20971] CJK UNIFIED IDEOGRAPH-4E00..CJK UNIFIED IDEOGRAPH-9FEAF900..FA6D    ; Han # Lo [366] CJK COMPATIBILITY IDEOGRAPH-F900..CJK COMPATIBILITY IDEOGRAPH-FA6DFA70..FAD9    ; Han # Lo [106] CJK COMPATIBILITY IDEOGRAPH-FA70..CJK COMPATIBILITY IDEOGRAPH-FAD920000..2A6D6  ; Han # Lo [42711] CJK UNIFIED IDEOGRAPH-20000..CJK UNIFIED IDEOGRAPH-2A6D62A700..2B734  ; Han # Lo [4149] CJK UNIFIED IDEOGRAPH-2A700..CJK UNIFIED IDEOGRAPH-2B7342B740..2B81D  ; Han # Lo [222] CJK UNIFIED IDEOGRAPH-2B740..CJK UNIFIED IDEOGRAPH-2B81D2B820..2CEA1  ; Han # Lo [5762] CJK UNIFIED IDEOGRAPH-2B820..CJK UNIFIED IDEOGRAPH-2CEA12CEB0..2EBE0  ; Han # Lo [7473] CJK UNIFIED IDEOGRAPH-2CEB0..CJK UNIFIED IDEOGRAPH-2EBE02F800..2FA1D  ; Han # Lo [542] CJK COMPATIBILITY IDEOGRAPH-2F800..CJK COMPATIBILITY IDEOGRAPH-2FA1D
# Total code points: 89228

囊括了所有统一表意文字、中日韩兼容性字符、苏州码子、「〇」、「〆」、「々」以及字典常用的部首。从前面汉文（Han Script）与汉字（CJK Ideograph）的关系我们可以知道，/\p{Script=Han}/u匹配的是汉文作为一个字符集里面的所有字符，因此它包括了部首、「々」等字符，这些字符要么当它们独立存在的时候没有语言意义（部首独立存在是一个符号），要么无法独立存在（「々」依赖于所修饰的汉字）。所以汉字是汉文的一个单元，汉文除了包含汉字以外，还包括这些部首符号、数字、修饰符。因此使用/\p{Script=Han}/u来匹配汉字混淆了汉文与汉字的概念范围。

浏览器兼容性支持

JavaScript

截至2019年10月，Chrome 64 以上, Safari 11.1 以上都支持 正则表达式 Unicode 属性转义。对于其他浏览器，我们推荐使用 7.7 版本的@babel/env转译配置将带有属性转义的正则表达式转为 Unicode 码点正则表达式。

1
2
3

{
  "presets": ["@babel/env"]
}

就可以根据browserslist指定的浏览器版本自动决定是否进行此特性的转译。注意 Babel 7.3 - 7.6 的版本对此特性支持产生了问题，该问题已经在PR 10447得到解决，将随 Babel 7.7.0 一同发布。

如果您还在使用更老一点的 Babel 7.x 版本，需要用babel转译插件@babel/plugin-proposal-unicode-property-regex。@babel/env 背后也使用了这个插件。

上述转译结果的在线演示可以在这里查看，开发者可以自己在上面转译其他的 Unicode 属性转义正则表达式。我们在这里列举/\p{Unified_Ideograph}/u转译成Unicode 码点正则表达式的结果：

1
2
3

const regex = /\p{Unified_Ideograph}/u;
// transpiled to ES6:
const regex = /[\u3400-\u4DB5\u4E00-\u9FEA\uFA0E\uFA0F\uFA11\uFA13\uFA14\uFA1F\uFA21\uFA23\uFA24\uFA27-\uFA29\u{20000}-\u{2A6D6}\u{2A700}-\u{2B734}\u{2B740}-\u{2B81D}\u{2B820}-\u{2CEA1}\u{2CEB0}-\u{2EBE0}]/u;

从上面这个正则表达式可以知道，转译的结果跟

3400..4DB5    ; Unified_Ideograph # Lo [6582] CJK UNIFIED IDEOGRAPH-3400..CJK UNIFIED IDEOGRAPH-4DB54E00..9FEA    ; Unified_Ideograph # Lo [20971] CJK UNIFIED IDEOGRAPH-4E00..CJK UNIFIED IDEOGRAPH-9FEAFA0E..FA0F    ; Unified_Ideograph # Lo   [2] CJK COMPATIBILITY IDEOGRAPH-FA0E..CJK COMPATIBILITY IDEOGRAPH-FA0FFA11          ; Unified_Ideograph # Lo       CJK COMPATIBILITY IDEOGRAPH-FA11FA13..FA14    ; Unified_Ideograph # Lo   [2] CJK COMPATIBILITY IDEOGRAPH-FA13..CJK COMPATIBILITY IDEOGRAPH-FA14FA1F          ; Unified_Ideograph # Lo       CJK COMPATIBILITY IDEOGRAPH-FA1FFA21          ; Unified_Ideograph # Lo       CJK COMPATIBILITY IDEOGRAPH-FA21FA23..FA24    ; Unified_Ideograph # Lo   [2] CJK COMPATIBILITY IDEOGRAPH-FA23..CJK COMPATIBILITY IDEOGRAPH-FA24FA27..FA29    ; Unified_Ideograph # Lo   [3] CJK COMPATIBILITY IDEOGRAPH-FA27..CJK COMPATIBILITY IDEOGRAPH-FA2920000..2A6D6  ; Unified_Ideograph # Lo [42711] CJK UNIFIED IDEOGRAPH-20000..CJK UNIFIED IDEOGRAPH-2A6D62A700..2B734  ; Unified_Ideograph # Lo [4149] CJK UNIFIED IDEOGRAPH-2A700..CJK UNIFIED IDEOGRAPH-2B7342B740..2B81D  ; Unified_Ideograph # Lo [222] CJK UNIFIED IDEOGRAPH-2B740..CJK UNIFIED IDEOGRAPH-2B81D2B820..2CEA1  ; Unified_Ideograph # Lo [5762] CJK UNIFIED IDEOGRAPH-2B820..CJK UNIFIED IDEOGRAPH-2CEA12CEB0..2EBE0  ; Unified_Ideograph # Lo [7473] CJK UNIFIED IDEOGRAPH-2CEB0..CJK UNIFIED IDEOGRAPH-2EBE0# Total code points: 87882

使用

1
2
3
4
5

{
  "plugins": [
    ["@babel/plugin-proposal-unicode-property-regex", { "useUnicodeFlag": false }]
  ]
}

配置将表达式转成 ES5 支持的以字符的 UTF16 表示为序列的字符串，这里不再赘述。

input 元素的 pattern 属性

在前端技术中，除了JavaScript会用到正则表达式，HTML 里<input>元素的pattern属性也会用到正则表达式。与 JavaScript 相比，pattern不支持设置正则表达式的标志位，因此 HTML 标准中强制规定了 input 元素的 pattern 属性需要施加unicode标志⁶。目前除了 IE 和 Edge 18 以外的主流浏览器都已经实现了这一标准。

在 React/Angular/Vue.js 三大前端框架中，Angular 提供了近似于 pattern 的指令 ngPattern。目前ngPattern尚未施加unicode标志⁷。AngularJS 的 ngPattern directive 仍未施加。

在大部分情况，是否施加unicode标志不会对正则表达式产生语义区别。主要的差别在于：

• 在使用\u{10000}表示 Unicode 码点字符情形，正则表达式/\u{10000}/代表匹配u一万次，/\u{10000}/u匹配字符\u{10000}一次
• /./只匹配 BMP 平面的字符，/./u匹配所有平面的字符。

由于 Unicode 属性转义正则表达式需要 Chrome 64 以上，Safari 11.1 以上，因此下面的用法目前只能在这些浏览器中使用：

1

<input type="text" pattern="\p{Unified_Ideograph}">

因此，如果需要兼容其他浏览器，可以使用转译插件的底层库regexpu-core在 JavaScript 中转换正则表达式，再把转换结果通过 HTML 模版输送过去中，但无疑这是一个很麻烦的做法。

1
2
3
4
5
6

const rewritePattern = require("regexpu-core");
rewritePattern('\\p{Unified_Ideograph}', 'u', {
  'unicodePropertyEscape': true,
  'useUnicodeFlag': false
});
// → '/(?:[\u3400-\u4DB5\u4E00-\u9FEA\uFA0E\uFA0F\uFA11\uFA13\uFA14\uFA1F\uFA21\uFA23\uFA24\uFA27-\uFA29]|[\uD840-\uD868\uD86A-\uD86C\uD86F-\uD872\uD874-\uD879][\uDC00-\uDFFF]|\uD869[\uDC00-\uDED6\uDF00-\uDFFF]|\uD86D[\uDC00-\uDF34\uDF40-\uDFFF]|\uD86E[\uDC00-\uDC1D\uDC20-\uDFFF]|\uD873[\uDC00-\uDEA1\uDEB0-\uDFFF]|\uD87A[\uDC00-\uDFE0])/'

总结

1. /[\u4e00-\u9fa5]/已经过时了，请不要再使用二十年前的正则表达式了。
2. /\p{Unified_Ideograph}/u不需要维护，匹配所有汉字。这里\p是 Unicode 属性转义正则表达式。
3. /\p{Ideographic}/u 和 /\p{Script=Han}/u 都是/\p{Unified_Ideograph}/u的超集，匹配了除了汉字以外的其他一些字符，在「汉字匹配正则表达式」这个需求下，是错的。
4. 目前 Chrome 和 Safari 支持 Unicode 属性转义正则表达式。对其他环境，使用 7.7 版本的 @babel/env 就可以自动根据浏览器规定打开支持。

一座温暖的南方城市，新的开始。

我庆幸可以在年终看自己做过的事情觉得幼稚而可爱，解决的问题那么简陋却又自诩折腾精神。这毕竟也意味着，这两年没有白过。

渐渐发现最痛快事还是精研标准，名正言顺。慢慢脱离了个人博客等信息源，可以一眼看出信息源的段位和水平；慢慢觉得知乎许多内容都是媒体创作，因而越来越挑剔。

今年在 GitHub 有 801 个贡献，去年是 275 个，还有许多是业务代码。这是去年没有想象到的。给 node.js、angular、moment.js 都贡献了代码，也是去年没有想象到的。

要说生活上最重要的，我觉得是「取舍」二字。「取舍」不是说这里要多一些，那里要少一些；而是干脆利落，该「取」则要大力出奇迹，该「舍」则要一毛不拔。比如说买五件同样的衣服，买两斤同样的糖果；比如说不买什么。物事越少，留给自己支配的注意力就越多。

要说学习上最要紧事，便是明晰概念，建构体系。少年时代在大学课堂上，最记得老师说的便是「明晰概念」，到自己去学习 Unicode 的时候，便觉得概念清晰才能举一反三，触类旁通。「纸上得来终觉浅，绝知此事要躬行」说得就是它。

一段对自己冲击比较大的旅行确实受益匪浅。比如坐了53个小时的火车到拉萨，清晨的高原，深受婆罗米系文字影响的藏文，与汉语有同源关系的藏语，寺庙上已经变成装饰意义的兰扎文，无不款款向我展开了生活奇妙的小径。

许多软件开发工作必然会被人工智能所取代，趁现在，不如早日把人类的过去历史进行数字化，打通人机间的信息交互之门。越来越觉得时间不够用的时候，只能自省学习的过程，争取早日给 Unicode 做贡献。

最后，让我们永远为文明进步而热泪盈眶。

附录

此篇附录与正文毫无关系，只是作者偷懒牵强贴上来的。

Fact: Two compatibily equivalent Unicode string does NOT have to share same length of grapheme clusters.

Example:

1
2
3
4
5
6
7
8

let a = "กํา"; // <0e01, 0e4d, 0e32>
let b = "กำ"; // <0e01, 0e33>
a.decomposedStringWithCompatibilityMapping == b.decomposedStringWithCompatibilityMapping
// returns true
a.count
// returns 1
b.count
// returns 2

所以默认的 grapheme cluster boundary 算法才说

do not have to cover edge cases that will not occur in practice.

因此 maxlength/minlength 这种跟用户密切相关，却又使用 JavaScript 字符串长度来判断的 HTML 属性，注定充满了混乱。

对于一个历史悠久又没有执行强制代码规范的代码库，全量格式化看起来是一件风险不可控的事情：它产生了大量的难以评估的格式改动，也使得格式化以后的代码库运行git blame几乎都会定位到进行格式化的人（而非是这段逻辑的上一次有意义的修改者）。相比之下，理想的做法似乎应该是渐进格式化：对于新代码，使用强制的代码规范；对于老代码，除非它被修改，不然不进行强制代码规范。

真的是这样子吗？

全量格式化风险并不随代码量变大而显著变大。 全量格式化往往会产生改变巨大的提交，代码改变得越多，看起来引入问题的风险就会越大。然而，对于代码格式器而言，代码格式器需要处理的是语言规范里面定义的有限几种语法结构的组合，绝大部分的业务逻辑代码都不会有像编译器的测试用例一般复杂的语法结构，对于代码格式器而言，只要代码库中的语法结构都被测试覆盖，改一百行代码和改十万行代码并没有本质区别。换言之，如果代码格式器出错，那么导致的代码错误一定很容易被查出来（因为同样的语法结构在系统各个角落都会用到）。只要十万行代码用到的语法结构组合不是一百行代码的语法结构组合的一千倍，那么全量格式化十万行代码引入的问题就不会是只格式化一百行代码的一百倍，因此全量格式化代码引入的风险关于代码量完全不成线性关系。

一致的代码风格降低开发成本。 全量格式化立刻使得代码库形成一致的代码风格，项目的每一个开发者都会备受鼓舞，一致的风格让开发者的阅读流不必被异常的代码格式阻断，对代码块的视觉识别也更加迅速（你的大脑很快习得了function后面一个空格的位置一定是一组参数，你不必为多一个或者少一个空格而额外消耗认知能力），配合上代码提交阶段的自动格式化，开发者甚至可以在开发过程中完全不需理会代码格式——反正最后提交时都会被计算机誊抄一遍进入到代码库中。

增量格式化容易扩大化合并时的代码冲突。 可是渐进代码格式化给我更多的安全感？在 GitFlow 的分支管理模式中，假设一个未被格式化的文件分别在特性分支和补丁分支有了改动，那么改动将会触发该文件的格式化，我们会在后面指出——当两个分支的同一个文件分别进行化后，合并时的冲突块大小将会被格式化放大（因为 git 并不理解哪些改动是格式化，哪些改动是修改业务逻辑），很快你将会淹没在无处不在的合并冲突之中，更糟糕的是，因为 git 不理解格式化和业务逻辑修改的区别，你需要仔细核对才能知道哪些改动压根没有修改业务逻辑，这无疑增大了合并的时候错漏的风险。

那么，不如毕其功于一役吧。

如何全量格式化 GitFlow 分支模型的代码库？

下图一个典型的采用 GitFlow 分支模型的代码库历史图

          *---* feature/foo         /*---*---*---* develop     \      *---*---* master       \   \        \   * hotfix/bar         \          *---* release/1.0.0       

在 GitFlow 模型中，考察分支的生命周期，假设所有分支都是根据需求合理存在的，可以发现：

1. 所有的 release 分支都是历史分支，它们不会再汇入到 master 分支

2. 所有的 hotfix 分支都将汇入 master 分支，hotfix 分支生命周期很短

3. 每一次发小版本的时候，master 分支作为 hotfix 的汇入者，也会汇入到 develop 分支

4. 每一次发大版本的时候，develop 分支会汇入到 master 分支，并从新的 master 分支拉出 release 分支

5. 所有的 feature 分支都将汇入 develop 分支

根据这个生命周期，我们可以按照以下策略对代码库进行格式化，下面我们简称这个策略为两步格式化：

一，准备代码格式化配置。对所有活跃分支准备好代码格式器的配置，我们不推荐全局安装代码格式器，而是把代码格式器作为项目的开发依赖，这样历史版本可以用老版本的代码格式器，新代码可以用到新的代码格式器。你可以从开发分支拉出一个分支增加格式器配置，再遴选到各个活跃分支。只添加格式化配置对代码业务不会产生影响。

二，挑选一个合适的时间点进行批量的格式化处理。我们建议是在刚发完小版本之后，此时 master 刚刚汇入 develop 分支。然后再将 develop 分支都汇入到开发中的 feature 分支。此时历史如图所示。

          *---*---* feature/foo         /       /*---*---*---*---* develop     \         /      *---*---* master       \        *---* release/1.0.0       

这个时候，这些分支的领先程度满足下面的关系：

feature 分支 > develop 分支 > master 分支

这里的>是严格领先，也就是 feature 分支包含了 develop 分支的所有改动，develop 分支包含了 master 分支的所有改动。

三，单独对历史分支格式化。 对所有的还在维护的 release 分支，进行全量格式化，通过测试后提交，在下面的历史图中，我们简单记 release/1.0.0 的全量格式化 commit 为 O。

四，格式化 master 分支。 从 master 分支新开一个专门进行格式化的 hotfix 分支，进行全量格式化，测试无误后，汇入到 master 分支，记这个格式化的 commit 为 A，此时历史如图所示。

          *---*---* feature/foo         /       /*---*---*---*---* develop     \         /      *---*---*---A master       \        *---*---O release/1.0.0       

五，合并 develop 分支，使用 ours 策略消解冲突。 将此时的 master 分支再次汇入到 develop 分支，如果有冲突，使用 develop 分支的文件：

1
2

git checkout develop
git merge -s ours master

这里的-s ours指的是合并时的冲突消解策略。因为我们的分支满足上述的严格领先关系，develop 一定拥有所有 master 的改动，而 master 此时除了进行代码格式化，没有任何的业务逻辑改动（只要格式化工具不出错），因此冲突产生的原因一定不是业务逻辑产生的代码冲突，对于这些冲突，我们使用 develop 的文件一定不会影响代码业务；反过来，如果没有冲突，说明对这个文件进行格式化，大概率等同于将 master 分支的格式化改动合并过来的效果，因此，我们可以直接沿用这些格式化改动。记这个合并的 commit 为 M.

六，再次全量格式化 develop分支。 我们使用了 develop 分支自己的文件来消解冲突，而 develop 自己的文件是没有格式化的，因此，在合并完成后，我们再次进行全量的代码格式化，记这个格式化的 commit 为 B，此时分支历史如图所示。

          *---*---* feature/foo         /       /*---*---*---*---*---M---B develop     \         /   /      *---*---*---A master       \        *---*---O release/1.0.0       

现在，develop 和 master 仍然保持着严格领先的特点。

七，对于 feature 分支，重复上述步骤，将 develop 汇入 feature。 在下面的例子中，我们记 feature/foo 分支格式化的 commit 为 C，容易知道，格式化完成后，此时的分支历史如图所示。

          *---*---*-------*---C feature/foo         /       /       /*---*---*---*---*---M---B develop     \         /   /      *---*---*---A master       \        *---*---O release/1.0.0       

进行完这个流程后，我们仍旧保持着 feature 分支 > develop 分支 > master 分支的严格领先关系。

仔细考察此时的 develop 分支，我们发现 develop 分支的格式化实际上是两个 commit A 和 B 共同作用的效果。通过这种合并策略，我们相当于告诉 git，

develop 分支的格式化 = master 分支的格式化 A + Δ(develop - master) 的格式化 B

并且，所有格式化 A 导致的代码冲突已经在 M 得到消解，M 点的版本一定是可用的，而 develop 的代码符合规范又通过 commit B 得到了保证。

这样，当下一次发小版本时，master 汇入了新的 hotfix 并且再回流到 develop 时，我们一定无需处理格式化 A 导致的代码冲突，新的可能的冲突一定是 develop 新增的业务逻辑与 hotfix 改动之间的冲突——我们回到了格式化之前的冲突原因。

同时，当下一次发大版本时，由于 develop 总是领先于 master，并且 A 导致的代码冲突已经在 M 中得到了消解，我们也不会遇到合并冲突。

至此，我们完成了对代码库的全量格式化。

为什么不能对每一个分支做格式化再合并？

对每一个分支进行格式化是最容易想到的全量格式化方式，但它会扩大冲突块的大小，因为 git 只会记录文件改动，它不知道哪一些是代码格式化的改动，哪一些是业务逻辑的改动，我们不妨看一段简单的代码，看看格式化后的冲突块大小。为了简单起见，考虑只有 master 和 develop 分支的情形，源代码只有一个叫做 index.js 的文件。你也可以在这个仓库查看这个小项目的源代码与分支历史。此时历史如图所示。

  C master     /    A---B develop  

各个 commit 的 index.js 内容如下表显示

1

module.exports = function(foo){ return "foo" }

1

module.exports = function(foo){ return "foo" + "bar" }

1
2

function bar() { return "bar"; }
module.exports = function(foo){ return "foo" + bar() }

显然当 master 汇入到 develop 时，将会产生冲突，现在，我们分别格式化两个分支，并进行合并，此时index.js的冲突如图

1
2
3
4
5
6
7
8
9
10
11

<<<<<<< HEAD
function bar() {
  return "bar";
}
module.exports = function(foo) {
  return "foo" + bar();
=======
module.exports = function(foo) {
  return "foo" + "bar";
>>>>>>> master
};

显然，因为格式化与业务逻辑的变更混在了一起，此时整个index.js都发生了冲突，仔细观察 module.exports = function(foo) { 一行，显然这一行是格式化修改后的结果，业务逻辑修改与这一行无关，但由于分别格式化了原本就有冲突的分支，此时合并的时候格式化的改动也被视作冲突了（同时在不同的 commit 基础上把这一行改动成了module.exports = function(foo) {），因此，冲突块扩大了。

为什么不能合并完保持分支领先关系后，再对每一个分支分别格式化？

现在我们先将 master 合并到 develop 消解冲突，再分别进行格式化，此时历史如图。

  ----C---E master     /     \A---B---D---F develop  

其中F和E是格式化的 commit，现在我们把格式化后的 E 合并到 D，我们预期应该不会有业务逻辑产生的冲突，因为 B 和 C 的冲突在 D 中已经消解过了，然而，由于 E 和 F 都分别格式化了 C 和 D 中的内容，此时产生了单纯由格式化产生的冲突。

1
2
3
4
5
6
7
8
9
10
11

<<<<<<< HEAD
function bar() {
  return "bar";
}
module.exports = function(foo) {
  return "foo" + bar();
=======
module.exports = function(foo) {
  return "foo" + "bar";
>>>>>>> master
};

这个冲突和上面居然是一样的。这是因为在 D 中我们可以单纯地使用 B 作为消解冲突的方式，最后的结果和分别格式化分支是一样的。尽管这是冲突消解的一个特例，但这已经能证明，即便是在消解后严格领先的分支进行分别格式化，依然有可能扩大冲突块的规模。

使用两步格式化策略后的 hotfix 合并

使用两步格式化后的 git 历史如图。

  ----C---E master /     \   \A---B---D---F---G develop

其中 E 是对 master 分支的格式化，G 是对 develop 分支的增量格式化，我们下面对 master 分支进行一个 hotfix G

1
2
3
4
5
6
7
8
9
10
11

diff --git a/index.js b/index.js
index 93d99d6..fad8cfb 100644
--- a/index.js
+++ b/index.js
@@ -1,3 +1,6 @@
 module.exports = function(foo) {
+  if (foo === undefined) {
+    return undefined;
+  }
   return "foo" + "bar";
 };

此时 F 的文件内容为

1
2
3
4
5
6

function bar() {
  return "bar";
}
module.exports = function(foo) {
  return "foo" + bar();
};

显然，G 的改动将会与 F 冲突，此时将 G 合并到 F，冲突如下

1
2
3
4
5
6
7
8
9
10
11
12
13

function bar() {
  return "bar";
}
module.exports = function(foo) {
<<<<<<< HEAD
  return "foo" + bar();
=======
  if (foo === undefined) {
    return undefined;
  }
  return "foo" + "bar";
>>>>>>> master
};

冲突块清晰地定位在module.exports函数的变更冲突，master 对foo做了校验，develop 又重构了bar函数，与上面例子中module.exports = function(foo) {都被标记成冲突比起来，此时代码风格的变更均不引起冲突。业务逻辑导致的代码冲突被隔离了出来。

最后，你可以到这个项目查看上面描述到的分支历史。

附录

如何在 git blame 中忽略掉庞大的全量格式化 commit，保证 git blame 的返回某一行与业务相关的修改信息？

截至2017年12月，git blame 不支持忽略某一个 commit。 Google 的 chrome 团队架构工具提供了 git blame 的一个替代命令：git-hyper-blame, 该命令支持项目指定 git blame 忽略掉一些特定 commit。macOS 用户可以通过

1
2

brew tap easyops-cn/homebrew-chromium-tools
brew install depot_tools

来安装。只有.git-blame-ignore-revs文件中有全量格式化的 commit，例如

1

21dad2b6c508a637be41de85cac07699ddbd1485 #格式化代码

那么使用git hyper-blame就可以指定 blame 的时候忽略 21dad2b6c508a637be41de85cac07699ddbd1485 这个 commit。

总结

只要格式化工具的测试样例覆盖了足够全的语法结构，全量格式化并不是一件风险不可控的事情。对于 GitFlow 分支模型的项目，从 master 分支出发，按照合并——消解——增量格式化的两步格式化策略，就可以轻松地让整个项目代码风格统一。后续配合 pre-commit 的自动格式化钩子，可以保证项目的代码风格是永续一致的。

原文链接：http://iamvdo.me/en/blog/smooth-corners-with-css-houdini
已得到原文作者 Vincent De Oliveira 授权翻译

最近，我在推特分享了一篇关于人机交互界面的视错觉的文章。我向来喜欢视错觉，但这篇文章传达了一个新观点：与几何上的正圆比起来，一个微调过的圆形有可能给人以更加圆的感觉，而这一点对于圆角矩形同样适用。同时，我也惊奇地发现苹果从 iOS 7 开始就对系统图标做了同样的调整。在数学上，我们称这个调整过的圆角矩形在为超椭圆。

与此同时，为了准备一场讲演，我做了一些关于 CSS Houdini 的绘图 API（Paint API）的实验。这个 API 定义了一种新的在浏览器的渲染阶段往 CSS 图像中添加内容的方式。简单地说，浏览器给我们提供了用程序绘制一个 CSS 图像并用作背景的能力。因此，我们应该可以很简单地绘制一个超椭圆。

几个星期后，Sketch 添加了一个平滑圆角（smooth corners）的功能。据我所知，平滑圆角实际上就是超椭圆。我喜欢「平滑圆角」这个名字，于是在这里给大家展示如何使用 CSS 绘制平滑圆角。

首先，我们给paintWorklet添加一个绘图模块¹。

1

(CSS.paintWorklet || paintWorklet).addModule('smooth-corners.js')

然后，在这个模块中，我们注册一个绘图过程（paint），名字叫做 smooth-corners，这个绘图过程必须提供一个paint方法来绘制超椭圆。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

registerPaint('smooth-corners', class {
  paint(ctx, size) {
    ctx.fillStyle = 'black'

    // n=4 时，绘制一个方圆形
    const n = 4

    let m = n
    if (n > 100) m = 100
    if (n < 0.00000000001) m = 0.00000000001
    const r = size.width / 2
    const w = size.width / 2
    const h = size.height / 2

    ctx.beginPath();

    for (let i = 0; i < (2*r+1); i++) {
      const x = (i-r) + w
      const y = (Math.pow(Math.abs(Math.pow(r,m)-Math.pow(Math.abs(i-r),m)),1/m)) + h

      if (i == 0)
        ctx.moveTo(x, y)
      else
        ctx.lineTo(x, y)
    }

    for (let i = (2*r); i < (4*r+1); i++) {
      const x = (3*r-i) + w
      const y = (-Math.pow(Math.abs(Math.pow(r,m)-Math.pow(Math.abs(3*r-i),m)),1/m)) + h
      ctx.lineTo(x, y)
    }

    ctx.closePath()
    ctx.fill()
  }
})

paint方法接受两个参数：

• ctx是一个PaintRenderingContext2D对象，这个对象实现了CanvasRenderingContext2D的一个子集，因此大多数情况下你可以用它绘制任何图形
• size是一个PaintSize对象，规定所绘制图形的大小

现在我们可以在 CSS 中调用这个paint()函数。执行这个函数，我们将会得到一个黑色的平滑圆角矩形。

1
2
3

.el {
  background: paint(smooth-corners);
}

为了简单起见，我们将生成的图像用作图层遮罩（mask）²，这样，我们就可以很容易地通过background设置想要的背景色、渐变、或者图像。

1
2
3
4

.el {
  background: linear-gradient(deeppink, orangered);
  mask-image: paint(smooth-corners);
}

视觉效果不错，但程序灵活性还不够。现在，我们只是画了一种特殊的超椭圆——方圆形³（注意代码中n = 4）。那么，我们如何画任意指数的超椭圆呢？比如说 iOS 使用了 n = 5。我们可以使用 CSS 自定义属性来达到目的。

首先，定义自定义属性--smooth-corners

1
2
3
4
5

.el {
  --smooth-corners: 4;
  background: linear-gradient(deeppink, orangered);
  mask-image: paint(smooth-corners);
}

然后从registerPaint方法中获取

1
2
3
4
5
6
7
8
9
10
11
12

registerPaint('smooth-corners', class {
  static get inputProperties() {
      return [
          '--smooth-corners'
      ]
  }
  paint(ctx, size, styleMap) {
    const exp = styleMap.get('--smooth-corners').toString()

    const n = exp
  }
})

注意到paint()方法接受第三个参数styleMap，这是一个StylePropertyMapReadOnly对象，本质上是一个 Map 对象，通过此对象可以获取在inputProperties定义过的属性的计算值。这里我们获取了--smooth-corners的属性值并传递给n.

至此，我们可以在 CSS 中使用--smooth-corners属性，这个属性甚至还可以被 CSS 动画动态调整，只要我们通过CSS.registerProperty注册这一属性（示例，参考 CSS 属性与值 API）。

截至发稿时，只有 Chrome 支持 Houdini 的 Paint API，因此我们使用渐进增强的方式提供绘制平滑圆角

1
2
3
4
5
6
7
8
9
10
11
12

.el {
  border-radius: 60px;
  background: linear-gradient(deeppink, orangered)
}

@supports (mask-image: paint(smooth-corners)) {
  .el.is-loaded {
    border-radius: 0;
    mask-image: paint(smooth-corners);
    --smooth-corners: 5;
  }
}

除此之外，因为 Houdini 是一个 JS-in-CSS 方案，我们最好等到 JavaScript 加载了之后再施加 CSS 属性。因此，我决定在元素上加上.is-loaded类来确保加载后应用样式。

在生产环境中，我们应该使用 PostCSS 插件来自动添加--smooth-corners的 CSS 实现。（译者注：截至发稿时还没有对应的 PostCSS 插件）

你可以使用支持这一特性的浏览器到 http://lab.iamvdo.me/houdini/smooth-corners 体验最终效果。

后记

简单来讲，使用 CSS 遮罩就是把路径外的元素遮盖掉（这也是遮罩的目的😁）。如果有需要，你也可以使用registerPaint直接绘制渐变或者图像（图像似乎目前支持很有限，你只能自己处理图像的情况）。

如果你想自己动手，可以参考其他绘制图像的实例：创建你自己的背景属性，比如background-opacity或者以属性之外的方式传递绘图参数：绘制四个角落出发的渐变。我很乐意分享你们的示例。