ブログの更新がとまっていましたが、また少しずつ更新してきたいと思います。 今回はtrie（トライ）の最近の話をしたいと思います。 trieはキー集合を扱うためのデータ構造の一種です。例えば、単語集合からなる辞書であったり、クロールしたURL情報を扱ったり、最近だと、KVS（Key Value Store)のようにキーを介してデータを保存、読み込みをしたりと様々な場面で利用されます。 同じようにキー集合を格納するデータ構造としてハッシュを利用する方法があります。キーからハッシュ値を計算し、その場所に文字列へのポインタを格納しておくデータ構造です。ハッシュを利用した場合とtrieを利用した場合の一番の大きな違いは、trieの場合だと、ある文字列から始まるキーを全て列挙する、いわゆる接頭辞探索ができることです。例えば”te”で始まる文字列を網羅的に調べることができます。木をたどって、”te”の下

rxはGoogle日本語入力（Mozc）でも使われているTrieのライブラリである。LOUDSというツリーを表す簡潔データ構造を使ってTrieを実現している。第2回自然言語処理勉強会@東京に行ってきて、そういえばrxは読んでなかったなと思ったので、ちょっとだけ読んでみた。あくまでもメモ書きである。絵があると100倍ぐらいわかりやすくなる気がするけどメモなので絵は描きません。 読んだのは現在公開されている最新版であるrx-1.0rc4。 rxというのとrbxという2つの機能がある。rxが実現しているのはあくまでもtrieで、値的なものとしてはノードIDしか取れない。rbxはノードIDのような整数から、任意の長さのバイト列を引っ張ってくるためのライブラリ。普通の配列は当たり前だが要素が固定長であるので、要素が可変長であるというところがrbxの大きな特徴である。 rxでのエッジに対する文字割り当

概要 marisa-trie では，1 byte のラベル（Single-byte（SB）ラベル）は各トライに格納し，2 bytes 以上のラベル（Multi-byte（MB）ラベル）は次のトライもしくは TAIL に格納するようになっています．そのため，SB/MB ラベルを区別するためのフラグを各ノードに持たせるとともに，SB ラベルを格納する領域と MB ラベルへのリンクを格納する領域を用意しています． 以下は，もう少し詳しい内容です． ノード単位での実装 フラグ・ラベル・リンクを格納する簡単な方法は，これらの要素を各ノードに区別なく持たせることです．しかし，SB ラベルを持つノードと MB ラベルを持つノードでは割り当てるべき領域の大きさが異なるため，かなりの無駄が発生します．例えば，SB ラベルの格納に 8 bits，リンクの格納に 20 bits を使うのであれば，フラグも併せて

概要 rank/select は簡潔データ構造（Succinct Data Structures）の核になる関数です．ビット列の k ビット目までに含まれる 0, 1 の数を求めるのが rank，k 番目の 0, 1 の位置（Index）を求めるのが select であり，ビット列の密度（1 の割合）によって，いろいろな実装があります． marisa-trie では，0, 1 の割合が極端に偏らないビット列を想定するとともに，32-bit 環境における性能の劣化を防ぐために，64-bit 整数を使わないようにしました．そのため，ほとんどの部分は以前に開発したライブラリからの流用ですが，新しく書き直した部分もあります．ちなみに，索引のサイズはビット列の長さ n bits に対して (1/4)n bits です． 基本 ビット列の実装 ビット列の格納には 32-bit 整数の配列を使っています

[2011/11/30 更新; std::(unordered_)map でメモリ使用量を見積もる - ny23の日記に従い，STL コンテナのメモリ使用量を計測] [2011/02/21 更新: marisa-trie 0.1.3; 発表資料（Prefix/Patricia Trie の入れ子による辞書圧縮） - やた＠はてな日記 にてこの記事の実験結果を引用されているので，以後原則更新しないこととする．なお，marisa-trie は 検索時間が短くなりました - やた＠はてな日記 にあるように，marisa-0.2.0-beta3 以降ではさらに検索が速くなっています．] [2011/02/18 更新: marisa-trie の仕様変更に伴い，追記の記述を整合性が取れるよう変更; 最新版では未確認] id:s-yata さんが marisa-trie を公開されたので，例によってベ

概要 トライのライブラリを公開しました．ドキュメントはまったく用意できていませんが，とりあえず使えます．（追記 2011-01-09）ドキュメントを追加しました． http://code.google.com/p/marisa-trie/ ドキュメント ベンチマーク 使い方 インタフェース ツール インストール ビルド・インストールの方法は configure と make です．以下のようにすればインストールできます． ./configure make make check sudo make install インストールせずに試したいという方は，make install を省略して，tools/ 内部のツールを使うなり，lib/marisa/trie.h を見て使い方を確認するなりしてください．インストールせずにライブラリを利用するには，lib/ 以下のヘッダすべてと lib/libm

トライを構築したときのノード数が分からない，TAIL を導入したときにサイズがどのくらい小さくなるのか分からない，そんな悩みに答えるちょっとしたツールのソースコードです． 各ノードのサイズとノード数が分かればトライのサイズは簡単に求まるので，トライについて少し試してみようという段階で便利かもしれません． 例えば，ダブル配列であればノード数 n に対して 4n bytes か 8n bytes が基本です．ただし，以下のツールは終端文字による遷移をカウントしないことに注意してください．後，TAIL の長さが m であれば，m bytes を追加することになります． また，LOUDS Trie であれば，木の表現に 2n bits，ラベルの保存に n bytes，終端フラグの保存に n bits，後は rank/select の索引に…という具合で 1.5n bytes くらいになると思います

Topcoder is a crowdsourcing marketplace that connects businesses with hard-to-find expertise. The Topcoder Community includes more than one million of the world’s top designers, developers, data scientists, and algorithmists. Global enterprises and startups alike use Topcoder to accelerate innovation, solve challenging problems, and tap into specialized skills on demand.

『Ideal Hash Trees』*1という論文を(必要なところだけ、だいたい)読み終わったので、そのメモ等。 概要 AMT(Array Mapped Trie)という基盤的なデータ構造を使って、ideal(nearly ideal)なHash Treesを作ろう、というような話。 AMTの応用例として、以下のようなものが説明されている。 Hash Array Mapped Trie(HAMT) ハッシュマップ 各種操作がO(1) ハッシュテーブルの初期サイズを(あまり)気にする必要がない 要素が増えた場合のリサイズのコストが小さい*2 リサイズ不要な実装も可能だがその場合はO(log N)に。※ Nは要素数。今回の実装はこっち。 成功検索時、キーの比較は一回しか生じない ただし、キーのハッシュ値の計算処理は(異なるハッシュ関数で)複数回行われることがある。 Clojureの組み込みのハ

Succinct なトライをサポートする sumire-tries があるにもかかわらず，ここしばらく，大規模なトライ用のライブラリを開発しています．sumire-tries を何度も修正したのは，開発の途中でいろいろと気づいて，それらを反映させていたからです．いわゆるオマケという感じです． 今回の開発目的は，sumire-tries より大規模なトライを扱うことです．そして，新しいライブラリの特徴は，以下のようになっています． 64 ビット環境に最適化 32 ビット環境でも使えますが，本来の性能は出ません． トライのサイズ制限なし ノード数の上限は 2^38 = 2700 億です． 一時ファイルの利用 主記憶容量を超えるサイズのトライを構築できます． 構築するだけなら主記憶容量を超えても問題ありませんが，メモリ上に展開できないため，検索するときに mmap() を使うことになります．おそ

いつものように，Google Code にアップロードしました．プロジェクトの名前は sumire-tries になっています．名前を sumire にした理由は，なんとなくです…． ドキュメントは準備中ですが，基本的な使い方は後述します． Google Code Archive - Long-term storage for Google Code Project Hosting. 右のメニューにある Featured downloads からアーカイブをダウンロードして，よくある手順を踏めば動作確認できます． ./configure make make check ヘッダのみで構成されているため，make install でインストールしなくても，ヘッダを格納しているディレクトリ（include/）をコピーすれば使えます． トライを構築する手順は，以下のようになっています． 基礎となる

実験の概要 Succinct な木構造を用いてトライを実装すると，コンパクトな辞書を構築できます．しかし，検索速度の面では，その他のデータ構造に劣るという欠点を持ちます．そこで，いくつかのトライを C++ で実装し，ちょっとした性能テストをしてみました．今回のテストで実装したトライは，以下のとおりです． BasicTrie 各ノードに「一つ目の子ノードの ID」，「兄弟ノードが存在するか」，「ラベル」を持たせたトライ 兄弟ノードが隣接するように配置 探索時，子ノードを線形探索して移動先を決定 TernaryTrie BasicTrie の各ノードに「子ノードの数」を加えたトライ 探索時，子ノードを二分探索して移動先を決定 DaTrie ダブル配列によるトライ 探索時，ラベルにより移動先を一意に決定 SuccinctTrie 「一つ目の子ノードを左の子」，「兄弟ノードを右の子」とする二分木に

適当な単語群を含む辞書があったとします。「京都の高倉二条に美味しいつけ麺のお店がある」*1という文章が入力として与えられたとき、この文章中に含まれる辞書中のキーワードを抽出したい、ということがあります。例えば辞書に「京都」「高倉二条」「つけ麺」「店」という単語が含まれていた場合には、これらの単語(と出現位置)が入力に対しての出力になります。 この類の処理は、任意の開始位置から部分一致する辞書中のキーワードをすべて取り出す処理、ということで「共通接頭辞検索 (Common Prefix Search)」などと呼ばれるそうです。形態素解析、Wikipedia やはてなキーワードのキーワードリンク処理などが代表的な応用例です。 Aho Corasick 法 任意のテキストから辞書に含まれるキーワードをすべて抽出するという処理の実現方法は色々とあります。Aho Corasick 法はその方法のひと

"A", "to", "tea", "ted", "ten", "i", "in", "inn" というキー群によるトライ木 トライ木（英: trie）やプレフィックス木（英: prefix tree）とは、順序付き木の一種。あるノードの配下の全ノードは、自身に対応する文字列に共通するプレフィックス（接頭部）があり、ルート（根）には空の文字列が対応している。値は一般に全ノードに対応して存在するわけではなく、末端ノードや一部の中間ノードだけがキーに対応した値を格納している。2分探索木と異なり、各ノードに個々のキーが格納されるのではなく、木構造上のノードの位置とキーが対応している。 キーが文字列である連想配列の実装構造としても使われる。右図の例では、ノードを表す丸の中にキーが書かれ、連想される値がその下に書かれている。値が書かれていないノードはキー文字列の途中までにしか対応していない。各英単語