Rabin-Karpは本当にローリングハッシュにmod Q操作を適用することに注意する必要がありますか？

私はRabin Karpアルゴリズムについて読んでいて、値Qによって制限されたローリングハッシュ値を維持することの大事なことは何だろうとずっと思い続けました。

一般的なコンピューターでの整数表現は2の補数であるため、実際には、ローリングハッシュに対するすべての操作を2 ^ 31で制限するのとまったく同じであると考えました。つまり、気にしないでください。さらに、バインドまたはハッシュする値が小さいほど、衝突が増えるため、Qが大きいほどパフォーマンスが向上します。

簡単な（Java）実装をコーディングしてみました。

public static int rabinKarp(String text, String pattern) {
    if (text.length() < pattern.length()) {
        return -1;
    } else {
        int patternHash = 0;
        int textHash = 0;
        int pow = 1;

        // preprocessing the pattern and the first characters of the text string
        for (int i = pattern.length()-1; i >= 0; --i) {
            patternHash += pattern.charAt(i) * pow;
            textHash += text.charAt(i) * pow;
            pow *= 10;
        }
        pow /= 10;

        // actual search
        if (patternHash == textHash && areEqual(text, 0, pattern)) {
            return 0;
        } else {
            for (int i = 1; i < text.length()-pattern.length()+1; ++i) {
                textHash -= text.charAt(i-1)*pow;
                textHash *= 10;
                textHash += text.charAt(i+pattern.length()-1);
                if (textHash == patternHash && areEqual(text, i, pattern)) {
                    return i;
                }
            }
            return -1;
        }
    }
}

いくつかの予備テストから、私の仮説は経験的に正確であるように見えますが、それがどこにも書かれていないので、疑問に思っています。

何か不足していますか？

はい、実際には、計算をオーバーフローさせるだけで問題ありません。あなたは効果的にモジュロを働いています$2^{32}$。また、（高価な）モジュロ計算を必要としないという利点もあります。ただし、理論的なパフォーマンス保証の一部が欠けています。ベースの選択には非常に注意する必要があります（この場合：$10$）モジュラスに関して。

特に、あなたの選択 $10$とても貧しいです。ご了承ください$10^{32}=2^{32}\cdot 5^{32}$、 そう $10^{32} \textrm{ mod } 2^{32} = 0$。つまり、最後の$32$ 文字列の文字はハッシュで考慮に入れられるため、アルゴリズムのパフォーマンスが非常に低い入力を構築できます。

干し草の山を $m$ $1$の、すなわち $1111111\ldots$ そして針はからなるひも $n$ $1$の、1 $0$、 その後 $32$ $1$の。文字列が$32$ $1$のすべての位置は偽のヒットとなり、アルゴリズムはループオーバーする必要があります $n$ $1$ゼロに遭遇する前の、つまり、 $\Omega(nm)$ 実行時間。

私は入力であなたのアルゴリズムをテストしました $n=3000,m=n^2=9\cdot 10^6$。それは取った$18$ 終了した入力で実行する秒数 $32$ 1ですが、 $200ms$ で終わる文字列の場合 $31$ $1$の。

問題はそれです $10$係数に対して比較的素数ではありません。たとえば、$9$ ベースがプログラムのパフォーマンスを大幅に向上させるため、 $200ms$ の場合 $32$ $1$の。もちろん、基数が自動的に相対的に素数になるため、素数係数を使用すると、この問題が部分的に解決されます。ただし、これが素数係数を優先する唯一の理由ではありません。

さて、モジュラスが $n$ そしてベース $b$比較的素晴らしく、望ましくないことがまだ発生する可能性があります。たとえば、$k$ そのため $b^k=1\textrm{ mod } n$。それは望ましくない$k$ ハッシュ関数はすべてを区別できないため、 $i^\textrm{th}$ すべてのキャラクター $i+k^\textrm{th}$キャラクター。数学的な用語では、次の順序が必要です$b$ モッド $n$ できるだけ大きくします。

の順 $b$ モッド $n$ 常に最大でもオイラー・ファイ関数 $\phi(n)$。素数のために$p$、 $\phi(p)=p-1$ プライム以外の場合 $n$小さくなります。だから取る$n$ 素数になることは、 $b^k$「役に立つ」こと。理想的には、$b$ 原始根を法として $n$、それを作る $b^k=1 \textrm{ mod } n$ の値を保持しません $0<k<\phi(n)$。

常にパフォーマンスが低いインスタンスを構築でき、敵からの「攻撃」から保護するために、ベースとモジュラスをランダムな値にする必要があることに注意してください。