一次寻找邻居单词列表的算法优化 | Tim's Blog
定义一个单词的邻居为,与其长度相同,有且仅有一个字母不同的其他单词。对于一个单词列表,计算所有单词的邻居列表。例如:单词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
时,这个算法的复杂度将为,线性时间。
其中本文的最后一个算法与第二章的变位词算法有相似之处。都是基于标识(索引)来解决问题。
而解决问题的关键在于发现问题可以用标识来解决,即邻居间的共性是存在一个共同的匹配,而每个单词的匹配都是有限的(跟单词的长度一致)
Read full article from 一次寻找邻居单词列表的算法优化 | Tim's Blog