は、任意の32ビットのチェックサムアルゴリズムがあります。入力されたデータのためのCRC32よりも32ビットのチェックサムアルゴリズムが優れていますか？どちらかと
これらはCRC32に関連しています。私は実際には32ビットの記憶スペースの制限のために、最初の特性を数えていません。しかし、2番目の...のように見えるかもしれない改善される可能性があります。
アイデア？ありがとう。 （私は具体的な実装が必要ですが、C言語では優れていますが、C++/C＃などで始めるのもOKです）。
約MurmurHash？これはsaidであり、このハッシュは良好な分布（カイ2乗検定を通過する）と良好なアバランシェ効果を有することがわかる。また、非常に良いコンピューティング速度。
最初の基準ではありません。 32ビット出力を持つ適切に設計されたハッシュ関数は、入力の任意の対に対して衝突の1/2^32チャンスを有する。 2番目の基準はあまりよく定義されているわけではありませんが、統計的なテストがありますが、誰かが行っていると確信しています（衝突間隔についてはカイ二乗ですか？）。実装が必要な場合は、よく知られているハッシュの実装ではない、ハッシュ関数の提案されたコードを受け入れないことを強くお勧めします。これは、セキュリティ上の問題や、独自のハッシュや暗号化。よく知られてはいるが悪いハッシュ関数は、後者の方がうまくテストされ、「良い」衝突分布を持っていても、あなた自身が設計したものよりも優れています。
CRC32はこの定義によって「うまく設計されたハッシュ関数」ですか？特定の種類のエラーを検出するように設計されているので、特定の種類の違いがある入力は、他の種類の違いを犠牲にして検出の確率が高い（つまりCRC値が異なる）ことが期待されます。 –
エラー修正システムでチェックサムとして使用しているのですか、ハッシュ関数として使用して、ハッシュを比較して2つの入力が異なることをおそらく検出していますか？エラー訂正コードおよびハッシュ関数は、異なる望ましい特性を有する。 CRC32の場合、ノイズの多い回線で期待される種類のエラーを検出するように特別に設計されています（1ビットまたは数ビットの違い、どちらが確実かはわかりません）。 –
私は小さなデータの2つの区画を比較するためにハッシュ関数としてそれを使用しています。 （<1KB）。しかし、私は32ビットのハッシュを余儀なくされています。 –