整数列圧縮アルゴリズムの最前線 - ny23の日記
ちょうど二年ぐらい前，機械学習で疎ベクトルの圧縮に情報検索でよく使われる整数列の圧縮技術を使うことを検討したことがあった（オンライン学習でキャッシュを実装してみた - ny23の日記）．そのときは，オンラインで圧縮し Disk に保存，圧縮したベクトルは陽にメモリに置かず読む（OS に任せる）という実装で，（Disk IO のオーバーヘッドが大きく）圧縮さえすれば何を使っても大差なしという身も蓋もない結論になった（結局2行で書ける最も単純な Variable byte code を採用）． それ以降は整数列圧縮アルゴリズムに関する知識も NewPFD ぐらいで止まっていたのだけど，つい先日，現時点で最速の圧縮アルゴリズムの提案＋ここ数年の主な整数列圧縮アルゴリズム（Simple-8b (J. Software Pract. Exper. 2010), VSEncoding (CIKM 20
30分でわかる高性能な圧縮符号vertical code - EchizenBlog-Zwei
検索エンジンの転置インデックスなどデータ列を小さいデータサイズで持たせたい、という状況がある。こういう場合圧縮符号を使うのが一般的でunary符号やgamma符号、delta符号など様々な種類がある。 圧縮符号の中でイチオシなのがvertical code(vcode)。これは岡野原(@hillbig)氏によって提案された圧縮符号で単純な仕組みでdelta符号並の性能を誇っている。 本記事ではvcodeのポイントを絞って30分でわかるように解説してみる。 vcodeは本棚に本を並べる作業を連想すると理解しやすい。本棚は予め高さが決まっているので全ての本が入るような本棚を用意する。つまり というようなものを想像する。 この本棚は8冊の本が並んでいるが左から5冊目の本が他よりも背が高い。このため5冊目の本に合わせて背の高い本棚が必要になる。だが他の本は5冊目の本ほどに背が高くないので、5冊目が
【アイディア】圧縮率向上のための構成支援ツール
【アイディア】圧縮率向上のための構成支援ツール 2011-03-28-1 [Idea][NLP] 日本語文字列の場合（に限らないけど）、使う字種を少なくするほど圧縮率が向上する。漢字をひらがなにすると情報量が減るので（「記者」を「きしゃ」と表記すると「汽車？帰社？貴社？」と曖昧性が増える＝情報量減少）、当たり前のことだけど。 ということで、圧縮率向上のための構成支援ツールがあると嬉しい。「この文字をひらがなにするとこれだけ圧縮率が上がります」と教えてくれたり。 ひらがな化の推薦順序はどういう漢字がひらがな表記率が高いかの統計データを使う。例えば「面白い」を「おもしろい」と書くのは一般的だけど「東京駅」を「とうきょうえき」とはあまり書かない、みたいな統計データ。コーパスから得ることができる。 既出ネタかな。 ちなみに手元にある100万文字ほどの日本語テキストとそれを形態素解析器通して読みだけ
整数列圧縮 その2 - NewPFD -｜JAVAでデータマイング！
JAVAでデータマイング！ 『情報工学の難しいそうなアルゴリズムをJAVAで実装して、ひたすらその結果を公開する』ブログになる予定。 PR Calendar <<April>> S M T W T F S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Theme NaiveBayes ( 2 ) スムージング ( 0 ) はじめに ( 1 ) 計算テクニック ( 0 ) 整数列圧縮 ( 2 ) 外れ値除去 ( 0 ) LSH ( 4 ) 協調フィルタリング ( 0 ) ブースティング ( 0 ) Kmeans ( 0 ) 階層的クラスタリング ( 2 ) EMアルゴリズム ( 0 ) BM ( 0 ) SVD ( 0 ) PLSI ( 0 ) LDA ( 0 ) パーセプトロ
DMC(Dynamic Markov Coding)のによるデータ圧縮プログラムを書いてみた - 遥かへのスピードランナー
最近Managing Gigabytes勉強会に参加しているのでせっかくなので、この本に載っているアルゴリズムを使ってプログラムを組んでみました。 今回実装したのは、「2.5 SYMBOLWISE MODELS」の後半で説明されている「Dynamic Markov Coding(DMC)」です。書籍の他に、元論文「G. Cormack and R. Horspool, "Data compression using dynamic Markov modelling,"」を参考にしました。 実装はC++で行い、ソースはgithubに置きました。（CentOS 5.2+gcc 4.1.2で動作確認済） http://github.com/thorikawa/MG/tree/master/dmc 以下、アルゴリズムの概要と実装上の工夫などをまとめてみます。 意見・指摘などは絶賛大歓迎です。 DM
Interpolative coding - tsubosakaの日記
今日のInterpolative codingの話が面白かったのと復号の部分のコードが必ずしも自明ではないかと思ったのでメモ。 Interpolative codingは長さと出てくる値の最小値、最大値が分かっている狭義単調増加な自然数のリストを圧縮する方法である。 ここで最大値とはリストの最大値ではなく、たとえば転置リストであれば最大の文書IDなど圧縮を行う際に出てきうる値の最大値である。 Interpolative codingの基本的な考え方としてはたとえば1から20までの数が表れるとわかっておりかつリストの長さが20であるということが分かっていれば、なにもデータがなくてもリストが[1..20]であるとわかるということに基づいている。 ここでは例で説明する。長さ7のリスト<7;3,8,9,11,12,13,17>を圧縮することを考える。またここで出てくる数の最大値は20であることが分
転置インデックスの圧縮 - tsubosakaの日記
Managing Gigabytes勉強会で転置インデックスの圧縮の話が出たので実際に圧縮を行った場合にどれくらいのサイズになるかを計測してみた。 利用したデータは英語版Wikidiaの全記事で 文書数 2,872,589 単語数 2,735,620 転置インデックスのポインタの数 397,603,176 ぐらいのサイズのデータです。 無圧縮の転置インデックスのフォーマットは 単語ID,文書数,文書1,....文書N, 単語ID,...で各項目4byteとなっており、1.5Gぐらいのサイズになっています。 これに対して各圧縮アルゴリズムを適用した結果は アルゴリズム 無圧縮 Variable Byte Code unary符号 γ符号 δ符号 Rice Coding pforDelta(仮) サイズ 1537MB 497MB 239475MB 474MB 407MB 367MB 455MB
γ符号、δ符号、ゴロム符号による圧縮効果 - naoyaのはてなダイアリー
通常の整数は 32 ビットは 4 バイトの固定長によるバイナリ符号ですが、小さな数字がたくさん出現し、大きな数字はほとんど出現しないという確率分布のもとでは無駄なビットが目立ちます。 Variable Byte Code (Byte Aligned 符号とも呼ばれます) は整数の符号化手法の一つで、この無駄を幾分解消します。詳しくは Introduction to Information Retrieval (以下 IIR) の第5章に掲載されています。(http://nlp.stanford.edu/IR-book/html/htmledition/variable-byte-codes-1.html で公開されています) Variable Byte Code はその名の通りバイトレベルの可変長符号で、1バイトの先頭1ビットを continuation ビットとして扱い、続く 7 ビット
mots quotidiens.PPM, 言語モデル, Burrows-Wheeler Transform
電通大の情報理論の 韓太舜先生 の最終講義が3月にあって, スライドが ここから 見られるのを知った。 院生のときに 『情報と符号化の数理』 (岩波書店 応用数学)を読んで, その明晰な内容と込められた哲学に感動した ので, 感慨深いです。 16ページ目の内容が本当なら, Weber-Fechnerの法則が理論から導けるという ことなのだろうか.. フルテキストは1975年なので, 閲覧制限がかかっていて見れないのが残念。 他も, 全体的に非常に興味深いのですが, とりあえず最後がワラタ。(笑) 論文の準備のためにPPM,PPM*,CTWなど圧縮関係の論文を(完璧ではないと 思いますが), 色々読んでみた。 PPMについては, 北先生のところで1998年に, PPM*を使った言語モデルの話 が出ています。 さて, PPMは岡野原君が 言語モデルと 似ている という話を書いているのですが,
Burrows-Wheeler変換の線形時間アルゴリズム - DO++
研究紹介です。今夏のSPIRE 2009という学会で "A Linear-Time Burrows-Wheeler Transform using Induced Sorting", D. Okanohara, K. Sadakane, SPIRE 2009 pdf(draft) というのを発表します。これは与えられた文字列に対し接尾辞配列を経ないでBurrows-Wheeler変換を直接行うというもので、アルファベットサイズによらず入力長に対して線形時間で行えます。基本的なアイディアは昨年のInduced Sortingによる接尾辞配列の線形時間構築アルゴリズム（いわゆるSAIS）を接尾辞配列を使わないでシミュレートするものです。pushとpop操作だけからなり、そのまま外部記憶上での構築とかにも対応できるようになっています。 Burrows-Wheeler変換（BWT, Block S
Hirosuke YAMAMOTO's Home Page
山本博資のホームページへようこそ!! English version is here. プロフィール 研究分野 出版物 スケジュール 山本-國廣研特別ゼミ 学会活動 オフィス，アクセス 写真 大学院生(修士/博士/社会人ドクター)の受け入れおよび大学院入試の情報 【ソフト公開】 ３次元グラフィックス用言語T3 （Tombow (トンボ) graphics for 3-dimensional drawing）公開中 【学内リンク】 東京大学： 大学院新領域創成科学研究科： 複雑理工学専攻 : 山本-國廣研究室 工学部： 計数工学科 : 数理情報第１研究室 大学院情報理工学系研究科： 数理情報学専攻 E-mail: Hirosuke (at) ieee.org
Canonical Huffman Codes での符号長の効率的な計算 - naoyaのはてなダイアリー
週末に参加した Managing Gigabytes の読書会で第2章のハフマン符号を担当しました。この中で Canonical Huffman Codes の解説がありますが、そこにハフマン符号の符号長を効率的に求める手法の説明が含まれています。 輪講では時間切れのためこのアルゴリズムの解説が駆け足になってしまいましたので、改めて解説資料を作ってみました。2009 年の今に Managing Gigabytes を読んでいるという方はあまり多くないかもしれませんが、参考になれば幸いです。 https://www.dropbox.com/s/539fhyc7rf6b9ik/090518computing_huffman_code_length.ppt?dl=0 (PPT, 258K) 先日 Canonical Huffman Codes の習作を Python で実装しましたが、このコード
Canonical Huffman Codes - naoyaのはてなダイアリー
1999年出版と少し古い書籍ですが Managing Gigabytes を読んでいます。理解のために 2.3 で出て来る Canonical Huffman Codes の習作を作りました。 ハフマン符号は情報圧縮で利用される古典的なアルゴリズムで、圧縮対象データに出現するシンボルの出現確率が分かっているときに、その各シンボルに最適な符号長の接頭語符号を求めるものです。 通常のハフマン符号はポインタで結ばれたハフマン木を構築して、ツリーを辿りながら各シンボルに対する接頭語符号を計算します。このハフマン木には曖昧な箇所が残されています。ハフマン木は木の辺を右に辿るか左に辿るかで符号のビットが決まりますが、右が 0 で左が 1 などというのはどちらでも良いという点です。(曖昧だから駄目、という話ではありません。) 従って、ハフマン木から生成される符号は一意には決まりません。 ここで各シンボル
素ハフマン圧縮プログラム。 - hogelogの日記
なんか、ハフマン符号化が少しわかった気がするぞ。あと二分木とか。プログラムを書いてようやく。実践を伴わない知識っていうのは宙に浮いてるようで、なんか居心地が悪い。実際に使ってみると、なんだか錨で固定したような気分になれるなあ。二分木に関しては「たぶんこんな感じのデータ構造だったっけ？」と適当に使ったから、スゲー間抜けなことしてるかも。というかそんなこと言い出したら全部そうか。 まず元データを読み込み、バイトごとの出現回数を数える。この出現回数表を書庫の先頭に記述。その回数からハフマン木を作成。ハフマン木により、1バイト->ビット列の変換表を作成。元データを頭から読み込み、先の変換表により書庫に追記。 というプログラムを作成。 以下ソース。 #include <stdio.h> #include <string.h> #define HCODEMAX 256 typedef struct{
LZ77圧縮
じゅげむじゅげむごこうのすりきれかいじゃりすいぎょのすいぎょうまつうんらいまつふうらいまつくうねるところにすむところやぶらこうじのぶらこうじぱいぽぱいぽぱいぽのしゅーりんがんしゅーりんがんのぐーりんだいぐーりんだいのぽんぽこぴーのぽんぽこなーのちょうきゅうめいのちょうすけ 符号 辞書幅(Byte) ■英数字 ■英数字+記号 ■ASCII ■ASCII+半角カナ1 ■ASCII+半角カナ2 ■原型 ■16進数用1 ■16進数用2 ■16進数用3その他の設定 \uF8F0-\uF8F3を使わない 連長圧縮しない 仕様任意の文字列を190種類程度の半角文字で表現します.使用する文字は以下から選択.1～5番目までは圧縮率が高まっていく傾向にあります.Byte数は文字CodeをShift-JISと見なして算出 [英数字]任意の文字列を英数字のみからなる文字列[0-9A-Za-z_]に変換します
Pizza&Chili Corpus -- Compressed Indexes and their Testbeds
The new millennium has seen the born of a new class of full-text indexes which are structurally similar to Suffix Trees and Suffix Arrays, in that they support the powerful substring search operation, but are succinct in space, in that it is close to the empirical entropy of the indexed data. They are therefore called compressed Suffix Trees and compressed Suffix Arrays, or in general compressed i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
LZMAかLZOか - GBA homebrew日記
Algorithms with Python
gzipの代わりにxzを使おう | Okumura's Blog
Huffman Encoding/Decoding Program