かなり..しかし、28% は「誤差の推定値」になります。
つまり、報告された 78% の測定値は、わずか 50% の類似性から簡単に得られることを意味します。または、50% の類似性が 22% と簡単に報告される可能性があります。私には、ビジネスの期待に十分に正確に聞こえません。
数学的には、2 桁を報告している場合、2 番目が意味を持つはずです。
なぜハッシュ関数の数を 12 に減らしたいのですか? 「200 のハッシュ関数」が実際に意味することは、各シングル/文字列に対してまともな品質のハッシュコードを 1 回計算し、次に 200 の安価で高速な変換を適用して、特定の要素を強調したり、特定のビットを前面に出したりすることです。
ビット単位のローテーション(またはシャッフル) とXOR 演算を組み合わせることをお勧めします。各ハッシュ関数は、いくつかのビット数でローテーションを組み合わせてから、ランダムに生成された整数で XOR することができます。
これにより、ビットの周りに min() 関数の選択性が「広がり」、min() が最終的にどの値を選択するかが決まります。
ローテーションの理論的根拠は、「min(Int)」が 256 回のうち 255 回、上位 8 ビットのみを選択することです。すべての上位ビットが同じ場合にのみ、下位ビットが比較に影響を与えます。そのため、シングル内の 1 つまたは 2 つの文字だけが過度に強調されるのを避けるために、分散が役立ちます。
XOR の理論的根拠は、それ自体で、ビットごとのローテーション (ROTR) が 50% の時間 (左から 0 ビットがシフトインされた場合) 0 に向かって収束する可能性があり、それによって「別個の」ハッシュ関数が望ましくない結果を表示する可能性があるためです。一緒にゼロに向かって一致する傾向 - したがって、彼らが独立した帯状疱疹ではなく、同じ帯状疱疹を選択することになる過度の傾向.
MSB が負であるが、後続のすべてのビットが正である、符号付き整数の非常に興味深い「ビット単位の」癖があり、符号付き整数の場合、回転の収束傾向があまり目立たなくなります。unsignedの場合は明らかです。とにかく、これらの状況でも XOR を使用する必要があります。
Java には 32 ビットのハッシュコードが組み込まれています。また、Google Guava ライブラリを使用する場合は、64 ビットのハッシュコードを利用できます。
XORが必要であることを指摘してくれた@BillDimmの意見と粘り強さに感謝します。