一次寻找邻居单词列表的算法优化

朋友发来了一道题目进行讨论，题目的主体可以简化为如下：

定义一个单词的邻居为，与其长度相同，有且仅有一个字母不同的其他单词。对于一个单词列表，计算所有单词的邻居列表。

例如：单词

son

与

sun

为邻居，而与

song

不为邻居，因为它们长度不一样。

读者朋友们，看完这道题目后，请先进行独立思考，然后再展开阅读。p.s. 本文将不包含具体代码。

暴力法

第一个想法很直白，遍历所有单词，判断彼此是否为邻居，若为邻居，则将彼此加入到自己的邻居列表。

这个算法的复杂度为。n为单词的个数。当单词超过一万时，意味着有一亿次的邻居查找操作。

即使邻居判定的方法再高效，这个方法也是十分低效的。

请读者暂停阅读，思考一下如何优化。

第一次优化

根据邻居的定义，可知长度不同的单词一定不是邻居，所以对长度不同的单词的互相判断是否为邻居其实是不必要的。

可以先对单词列表进行一次预处理，将长度相同的单词放入到同一个列表中，然后对每一个这样的列表内进行彼此邻居的判定。

假设所有单词的长度可以均分为10份，则每一个列表的长度可约等

n/10

，整个的复杂度为，虽然还是，但是已经比之前的暴力法要高效好几倍。

已经考虑到这一步的同学请再次暂停，思考有无数量级上提升的解决方案。

第二次优化

由于第一次优化并没有将实质性的复杂度降低，所以在单词很多的情况下还是比较低效。

我们需要重新审题，看能不能发现一点什么。

了解正则表达式的同学都知道，

s?n

这个匹配可以匹配

son

，也可以匹配

sun

。也就是说

s?n

是

son

和

sun

的共同匹配。而

?un

则是

sun

和

gun

的共同匹配。

邻居单词之间都有某种联系，这种联系就是它们都有一个共同的匹配。所以，我们可以遍历所有单词，建立以匹配为键，匹配的单词列表为值的字典，然后遍历每个匹配的单词列表，这些单词列表中的所有单词都互相为对方的邻居单词。

例如：

当遍历到单词

sun

时，

sun

有三个匹配，

[?un,
s?n, su?]

。匹配字典中将加入这几个匹配，这时候字典的内容为

{
?un=>[sun], s?n=>[sun], su?=>[sun] }

。

当遍历到单词

son

时，

son

有三个匹配，

[?on,
s?n, so?]

。匹配字典中将加入这几个匹配，这时候字典的内容为

{
?un=>[sun], s?n=>[sun, son], su?=>[sun], ?on=>[son], so?=>[son] }

。其中，

son

和

sun

共同的匹配

s?n

对应的列表加入了

son

。

当遍历到单词

gun

时，

gun

有三个匹配，

[?un,
g?n, gu?]

。匹配字典中将加入这几个匹配，这时候字典的内容为

{
?un=>[sun, gun], s?n=>[sun, son], su?=>[sun], ?on=>[son], so?=>[son], g?n=>[gun], gu?=>[gun] }

。其中，

sun

和

gun

共同的匹配

?un

对应的列表加入了

gun

。

对于每一个单词，假设单词的长度为

L

，则单词有

L

个匹配。对于

n

个单词，则最多有

n*L

个匹配列表。假设最长的匹配列表的长度为

m

，则整个算法的复杂度为。由于每个单词的邻居不会太多，所以基本可以将

m

视为常数。所以整个算法的复杂度为。

如果当单词列表长度

n

远大于最长单词的长度

L

时，这个算法的复杂度将为，线性时间。

回顾

不知道有多少同学看过《编程珠玑》。这本书的第二章有一个

aha
moment

，表示忽然习得的灵感。

其中本文的最后一个算法与第二章的变位词算法有相似之处。都是基于标识（索引）来解决问题。

而解决问题的关键在于发现问题可以用标识来解决，即邻居间的共性是存在一个共同的匹配，而每个单词的匹配都是有限的（跟单词的长度一致）。