转载

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

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

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

例如：单词 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 。