タグ付けされた質問 「huffman-coding」

Char Code ==== ==== E 0000 i 0001 y 0010 l 0011 k 0100 . 0101 space 011 e 10 r 1100 s 1101 n 1110 a 1111 元のテキスト： 湖の近くで見られる不気味な目 エンコード済み： 0000101100000110011100010101101101001111101011111100011001111110100100101 ハフマンエンコーディングにセパレータが必要ないのはなぜですか？

17 coding-theory  encoding-scheme  huffman-coding 

ハフマン符号化、算術符号化、および範囲符号化の関係を理解し​​ようとするとき、ハフマン符号化の欠点が分数ビットパッキングの問題に関連していると考え始めました。 つまり、シンボルに240の可能な値があり、これをビットにエンコードする必要がある場合、8は256の可能な値を表すことができるため、「フル」8は必要ないとしても、シンボルごとに8ビットでスタックすることになります。シンボルごと。この問題の解決策は、「フラクショナルビットパッキング」と呼ばれるもので、乗算を使用して2のべき乗ではない「ビットシフト」が可能です。2のべき乗の乗算がシフトするのx * 2 == x << 1と同じようにx * 4 == x << 2、2のべき乗すべてに対して同様に続きます。そのため、代わりに乗算することにより、2のべき乗でない値で「シフト」し、小数ビットサイズのシンボルにパックできます。 。 この問題はハフマンコーディングと同様です。結局、長さが小数ビットサイズでなければならないコードが作成されるため、このパッキング効率は低くなります。ただし、フラシトンビットパッキングのソリューションは、固定サイズのシンボルを想定しているため、単に使用することはできません。 問題は、算術コーディングに似たものを達成するために、フラクショナルビットパッキングと同様のアイデアでハフマンコーディングを改善するための論文や解決策はありますか？（または反対の結果）。

11 information-theory  data-compression  coding-theory  entropy  huffman-coding 

質問する前に、定義の理解から始めて、混乱を避けるために、背景を説明します。 ハフマンコードは、ハフマンのアルゴリズムによって構築されたバイナリツリーから誘導されたバイナリコードです。 Hu–Tucker Codeは、アルファベット順の検索ツリーから生成されたバイナリコードです。ウィキペディアに よると（最適なアルファベットの二分木（Hu–Tuckerコーディング）の段落を参照）： 標準のハフマンコーディング問題では、任意のコードワードが任意の入力シンボルに対応できると想定されています。アルファベットバージョンでは、入力と出力のアルファベット順は同じでなければなりません。したがって、たとえば、はコード割り当てることができませんでした。ただし、代わりにまたは A = { a 、b 、c }あ={a、b、c}A = \left\{a,b,c\right\}H（A 、C） = { 00 、1 、01 }H（あ、C）={00、1、01}H\left(A,C\right) = \left\{00,1,01\right\}H（A 、C） = { 00 、01 、1 }H（あ、C）={00、01、1}H\left(A,C\right) =\left\{00,01,1\right\}H（A 、C） = { 0 、10 、11 }H（あ、C）={0、10、11}H\left(A,C\right) = \left\{0,10,11\right\}。これはHu–Tucker問題としても知られています。TCHuおよびAlan Tuckerの後に、この最適なバイナリアルファベット問題の最初の線形解を提示する論文の著者は、ハフマンアルゴリズムといくつかの類似点を持っていますが、これのバリエーションではありませんアルゴリズム。これらの最適なアルファベット二分木は、二分探索木としてよく使用されます。 私の質問は、そのような木の用途は何ですか？（アルファベットのバイナリツリー） オンラインで検索しようとしましたが、満足のいく答えが見つかりませんでした。 私はHu＆Tuckerの論文の主題に関する紹介も読みました： Optimal Computer Search TreesとVariable-Length Alphabetical …

7 binary-trees  huffman-coding