ハフマンコードVS Hu–Tuckerコード


7

質問する前に、定義の理解から始めて、混乱を避けるために、背景を説明します。

ハフマンコードは、ハフマンのアルゴリズムによって構築されたバイナリツリーから誘導されたバイナリコードです。
Hu–Tucker Codeは、アルファベット順の検索ツリーから生成されたバイナリコードです。ウィキペディアに
よると(最適なアルファベットの二分木(Hu–Tuckerコーディング)の段落を参照):

標準のハフマンコーディング問題では、任意のコードワードが任意の入力シンボルに対応できると想定されています。アルファベットバージョンでは、入力と出力のアルファベット順は同じでなければなりません。したがって、たとえば、はコード割り当てることができませんでした。ただし、代わりにまたは ={abc}HC={00101}HC={00011}HC={01011}。これはHu–Tucker問題としても知られています。TCHuおよびAlan Tuckerの後に、この最適なバイナリアルファベット問題の最初の線形解を提示する論文の著者は、ハフマンアルゴリズムといくつかの類似点を持っていますが、これのバリエーションではありませんアルゴリズム。これらの最適なアルファベット二分木は、二分探索木としてよく使用されます。

私の質問は、そのような木の用途は何ですか?(アルファベットのバイナリツリー)
オンラインで検索しようとしましたが、満足のいく答えが見つかりませんでした。
私はHu&Tuckerの論文の主題に関する紹介も読みました: Optimal Computer Search TreesとVariable-Length Alphabetical Codeですが、そのようなツリーの使用例を正確に理解することはできませんでした。

最適なツリー(つまり、ハフマンコード)によって引き起こされる、コンパクトで最適なプレフィックスコードの必要性をよく理解できます。これは圧縮に使用できますが、アルファベット順の二分木はどのように使用されますか?


1
しかし、コードが元の文字列と同じ順序である場合、それは素晴らしいことではありませんか?(そして、一連の単語のツリーとして見た場合、それはtrisとbinary search treeの両方です)。「なぜそれらを最適にしたいのか」というのは明らかではないでしょうか。
Hendrik Jan

@HendrikJan、はい。確かに。それらを最適にする理由は明らかです。それは私の主な言葉の悪い選択ですが、主な質問は残ります:そのようなコードにはどのようなアプリケーションがありますか?
so.very.tired 2015年

回答:


6

実例を挙げましょう。これは、私が一度書いたものと非常によく似ています。

ライブラリカタログシステムを実装しているとします。ライブラリカタログは、概念的にはドキュメントのコレクションです(おそらくMARC形式です)。このシステムのユーザーは、他の検索エンジンと同様にクエリを入力すると、一連のドキュメントを受け取ることができます。ユーザーは、結果セットをいくつかのフィールド(タイトルや作成者など)でソートし、結果セットを一度に1画面ずつ表示できるようにしたいと考えています。

ソートはよく理解されている問題です。ただし、これが大きなライブラリであり、検索で100,000の関連ドキュメントが返されたとします。明らかに、ユーザーはそれらのすべてを調べるつもりはありません!実際、ユーザーは結果の最初の2、3の画面(たとえば、50〜100のドキュメント)だけを見て、クエリが広すぎることに気づき、さらに絞り込むことができます。

さらに、ドキュメントの並べ替えキーにアクセスするには、ドキュメントを解析する必要があります。確かに、可能性のある並べ替えキーを、MARC(またはさらに悪いことに、SGML / XML)の解析を必要としない形式に抽出できますが、データを複製することになります。さらに、これらは私たちが話している文字列です。それらは可変長であるため、メモリとディスクの管理が困難になります。

したがって、固定サイズのフォーマットを試すことができます。たとえば、すべてのタイトルの最初のK文字を、あらかじめ決められたKについて取得し、ドキュメント番号でインデックス付けされたディスク上の配列に格納できます。次に、最初にそれらの文字列プレフィックス(つまり、バケット/基数の並べ替えなど)でドキュメントを並べ替え、同じバケット内にあるすべてのドキュメントをドキュメントから「実際の」並べ替えキーを抽出して並べ替えることができます。

これの良い点は、結果セットを完全にソートする必要がないことです。ユーザーはセット全体をページングしているため、最初の数画面を完全に並べ替えるだけでよく、ユーザーがそこまでページを移動することを決定した場合、他の並べ替えに十分なバケット情報を保持するだけです。

これは改善ですが、Kをどのように設定しますか?多くのタイトルは「The」の文字で始まり、それは非常に小さな差別力のために32ビットの情報を使用しています。実際、「The International Journal of X」または同様のボイラープレートと呼ばれる定期刊行物がいくつあるかに驚かれることでしょう。一部の検索では、同じようなタイトルの同様のタイトルのドキュメントが多数返される可能性があります。

可能な解決策の1つは、順序を保持するコードを使用することです。そのコードを使用してすべてのタイトルを圧縮し、圧縮されたタイトルの最初の64ビット(またはその他の固定量)をディスク上の配列に格納します。これにはかなりの数の実用的な利点があります:識別力がほとんどないタイトルの部分は非常に短いコードワードを取得します(そのため、無関係な詳細でスペースを無駄にしないでください)。固定長です(したがって、効率的な方法で管理するのは簡単です)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.