0

大量の 2048 ビット バイナリ文字列 ('0111001...0101' など) を含む MySQL データベースを持っています。必要な計算の 1 つは、外部で生成されたビット文字列と比較したこれらの文字列のハミング距離 (XOR の結果に含まれる 1 の総数) です。このクエリの書き方を理解するために、小さなビット文字列用に書いてみました。次に例を示します。

select BIT_COUNT(bin((b'0011100000') ^ (b'1111111111')))

XOR を計算する内部部分は正しく機能しますが、BIT_COUNT は奇妙な結果を返します。この例では、文字列自体よりも長い 14 が返されます。

だから私はいくつかの質問があります:

まず、BIT_COUNT がこのような奇妙な結果を返すのはなぜですか。操作したいバイナリ文字列ではなく、文字列で操作していますか? もしそうなら、どうすればこれに対処できますか?

次に、先頭に b を付けて文字列をバイナリとしてキャストしていることに注意してください (これは正しい言葉ですか?)。列名と変数でこれを行うにはどうすればよいですか? 明らかに、変数名の前に単純に ab を追加することはできず、間にスペースを挿入することもできません。何か案は?

ありがとう、

編集:最初の問題の解決策は次のとおりです。

select BIT_COUNT(b'0011100000' ^ b'1111111111')

これをより大きな文字列 (2048 ビット) に使用すると問題が発生するようです。私は試した:

select BIT_COUNT(b'001110...00011')

実際のビットカウントは約 1024 であるはずの 28 のような結果が得られます。b を削除すると、64 で最大になるように見えます。この問題を解決する方法について何かアイデアはありますか?

4

1 に答える 1

1

機能を削除するだけbinです。BIN_COUNT引数をビットのセットとしてではなく、文字列として扱います。そう

select BIT_COUNT(b'0011100000' ^ b'1111111111')

仕事をします

于 2011-11-29T03:05:22.680 に答える