• AC自动机——多模式串匹配的算法思想


      标准KMP算法用于单一模式串的匹配,即在母串中寻求一个模式串的匹配,但是现在又存在这样的一个问题,如果同时给出多个模式串,要求找到这一系列模式串在母串存在的匹配个数,我们应该如何处理呢?

      基于KMP算法,我们能够想到的一个朴素算法就是,枚举这多个模式串,然后进行多次KMP算法,这个过程中完成计数,假设这里有n个模式串,那么整个算法的复杂度大约是O(n*m),m是母串的长度,这里的时间复杂度是粗略估计,没有计算辅助数组的时间(KMP中的next数组),但是这种复杂度还是太高,没有做到KMP算法中“成分利用已知信息”的核心思想,这里有一个巧妙的算法——AC自动机,能够线性的完成多模式串的匹配,即时间复杂度能够优化到O(m)。

      下面简单的介绍一下解决多模式串匹配问题的AC自动机算法的思想。

      回想起KMP所呈现的思想,我们在匹配之前需要充分挖掘模式串中所蕴含的信息,我们通过求得模式串的next数组,使得我们在遍历母串的时候得到了极大的优化,那么这里对于多模式串的匹配,应该采取相同的思路,我们应该对多个模式串所蕴含的信息进行充分挖掘。

      由多模式串朴素的二维数组的存储,为了节省空间,我们又会联想到之前的字典树,这里我们基于多个模式串,建立一个字典树,然后线性扫母串的时候,就是在这样一个字典树上扫。

      再次回想KMP中匹配过程,求得next数组时候,我们在母串上移动模式串完成匹配,基于next数组,我们得到的优化使得在模式串匹配失败之后,能够极大限度的往母串的右侧移动同时能够保证不漏掉任何匹配情况。但是在AC自动机这里,做法上有点区别,但是思想是一致的。做法上的区别体现在,基于多模式串的字典树上,我们将母串在字典树上进行匹配,我们在构造字典树的时候,记录模式串的最后一个字符作为终止节点,那么母串在字典树上匹配到终止节点的时候,就表明完成了一个模式串的匹配。

      那么现在我们需要完成的就是匹配失败后的优化,在母串区间str[i]~str[j]匹配失败以后,最优的做法应该是,求得str[i]~str[j]这段字符串最长的公共前缀和与后缀和,然后继续从这个最长的前缀和这条支路下,继续进行匹配。为了完成这一步“极大限度的往母串的右侧移动同时能够保证不漏掉任何匹配情况”,我们在字典树每个节点处设置一个“匹配失败跳转”指针(下文统称fail指针),记录如果在该点匹配失败,最优化的情况下我们应该跳转到的字典树的位置。

      能够看到,整个AC自动机呈现的多模式串匹配其实和KMP算法是高度的相似的。

      那么下面就需要解决的问题就是,就像计算KMP中的next数组,这里我们如何计算字典树里的fail指针。

      假设我们当前在找vi的fail指针,那么很显然,我们去找vi的父节点的fail指针所指向的节点vp,根据该指针的定义,很容易看到:

    (1)    如果当前节点vp的子节点vj能够与vi匹配,那么vi的fail指针必然指向vj。

    (2)    如果当前节点vp的子节点没有能够与vi匹配的,那么我们需要去找vp的fail指针指向的节点的子节点,看是否有与vi相互匹配的,没有的话,循环操作。

      对于(2)似乎形成了一个递归模式,为什么会这样呢?或者说这样做的正确性体现在哪里呢?它源于fail指针的定义,仔细的读者应该能够看到,fail指针本质上是一个描述一个字符串最长的公共前缀与后缀,对于一段字符串str[i]~str[j],失配之后我们在该段字符串最长公共前后缀(记作str[p]~str[j])的基础上,添加那个导致失配的字符a,但是字典树中可能不存在这种情况,难道我们就因此重新开始新的匹配么?当然不,我们再找一下字符串str[p]~str[j]的最长公共前后缀(记作str[k]~str[j]),添加那个导致失配的字符a,然后循环操作……

      这就是解决AC自动机的一个简答的思想描述。

      能够看到它与KMP算法思想同步到了一致,这启示我们学习过程中的触类旁通,这种现象在很多地方也有着很明显的体现(积分、二重积分、三重积分;一元函数、多元函数;单一变量分布、多变量联合分布)。很多思维思想在一维的角度建立,然后推广到二维角度甚至更高维度。

  • 相关阅读:
    Redux
    React-Router常见API
    webpack的plugin原理
    Kubernetes核心原理笔记
    阿里云证书过期时间监测
    DRF
    一个TCP可以发送多少个请求
    jenkins exporter(收集jenkins构建结果)
    Kubernetes SDN
    Django REST framework API认证(包括JWT认证)
  • 原文地址:https://www.cnblogs.com/rhythmic/p/5779370.html
Copyright © 2020-2023  润新知