0

13 種類のデータのセットから 13 の数字を描画しています。各種類には 4 つのアイテムがあるため、合計 52 アイテムです。項目に 1、2、3、4、5、6、7、8、9、10、11、12、13 の番号を付けることができるので、4 つの "1"、4"2"、... 4 になります。 「13」セット。セットから引き出される 13 の数字はランダムです。プロセス全体が 100 万回またはそれ以上繰り返されるため、13 の数値を効率的に格納する方法が必要です。何らかのコーディング方法を使用して、13 個の整数をビットに圧縮することを考えていました。たとえば、「1」、「2」の数を数えます...まず、各アイテムのカウントを 2 ビットでコーディングし、さらに 1 ビットを使用して、アイテムが描画されたかどうかを示します。したがって、アイテムごとに 3 ビットが必要で、合計 13 アイテムのコストは 39 ビットです。そのためには8バイトが必要です。しかし、数百万回または数十億回の計算について話していて、各セットを後でファイルに保存する必要があるため、それでも多すぎます。したがって、8 バイトを使用する場合でも、データ用に約 80 GB を要求します。ただし、それを半分に減らすことができれば、40GB 節約できます。この構造をより効率的に圧縮する方法はありますか? 代わりに 5 バイトを使用することも考えていますが、異なるタイプの数値 (1 つの int + 1 つの文字) を処理する必要があるのではなく、C++ のライブラリでコーディング/圧縮を簡単に行うことができますか? この構造をより効率的に圧縮する方法はありますか? 代わりに 5 バイトを使用することも考えていますが、異なるタイプの数値 (1 つの int + 1 つの文字) を処理する必要があるのではなく、C++ のライブラリでコーディング/圧縮を簡単に行うことができますか? この構造をより効率的に圧縮する方法はありますか? 代わりに 5 バイトを使用することも考えていますが、異なるタイプの数値 (1 つの int + 1 つの文字) を処理する必要があるのではなく、C++ のライブラリでコーディング/圧縮を簡単に行うことができますか?

ありがとう。

4

4 に答える 4

1

あなたのスキームでは、64ビットの8バイトで表される39ビットのすべてのハンドで25ビットが無駄になり、約40％になります。

手を一緒にバッチ処理すると、それらのビットを無駄にすることなくそれらを表すことができます。

39と64には共通の因子がないため、最小公倍数は39 * 64 = 2496ビット、つまり312バイトの倍数です。これは64ハンドを保持し、現在のスキームのサイズの約60％です。

于 2012-04-12T08:00:08.313 に答える
1

Google のプロトコル バッファは、その値に応じて、より少ないビット数で整数を格納できます。ストレージが大幅に削減される可能性があります。http://code.google.com/p/protobuf/を参照してください

実際のプロトコルについては、https ://developers.google.com/protocol-buffers/docs/encoding で説明しています。

圧縮に関しては、 zlibがデータを処理する方法を調べましたか?

于 2012-04-12T06:46:31.457 に答える
0

グーグルLV77とLVZ圧縮を試してみてください

于 2012-04-12T06:51:28.600 に答える
0

探しているものよりも少し洗練されているかもしれませんが、HDF5をチェックしてください。

于 2012-04-12T06:49:40.457 に答える