オープンソースのTrieライブラリまとめ - nokunoの日記
最近、趣味で開発しているStaKKのためにTrieライブラリを書いているのですが、参考にするためオープンソースのTrieライブラリについて調べました。簡潔データ構造を用いたものが中心です。 @hillbig氏によるもの tx LOUDSによる圧縮でメモリ使用量を削減したTrieライブラリ。 関連記事：Tx: Succinct Trie Data Structure Engineering the LOUDS Succinct Tree Representation - 射撃しつつ前転ux txの改良版。tailの圧縮によりtxの1/2くらいのサイズになるらしい。要チェック。 関連記事：ux... - ny23の日記id:s-yata 氏によるもの taiju LOUDSを含む簡潔データ構造を用いた大規模Trieライブラリ。sumire-triesインメモリの簡潔データ構造を実装した大規模T
Fast String Searching With Suffix Trees | Mark Nelson
Published in Dr. Dobb’s Journal August, 1996 I think that I shall never see A poem lovely as a tree. Poems are made by fools like me, But only God can make a tree. Joyce Kilmer A tree’s a tree. How many more do you need to look at? -Ronald Reagan The problem Matching string sequences is a problem that computer programmers face on a regular basis. Some programming tasks, such as data compression or
[プログラミング] Google Sparsehashを使うときの注意点 - tsubosakaの日記
持橋さんの書かれたgoogle-sparsehashと自作のsplay-treeとの速度比較をした結果の記事を読んで、さすがに速度に200倍近くの差がでるのはおかしいだろうということで原因を探ってみた。 結論としてはGoogle Sparsehashを使うときに__gnu_cxx::hashを使わない方がよいということが分かった。 時間の測定に用いられているコードは概ね以下のコードと同じである。 #include <iostream> #include <google/sparse_hash_map> #include <cstdio> #include <cstring> #include <ext/hash_map> using namespace std; using google::sparse_hash_map; typedef __gnu_cxx::hash<const cha
![[プログラミング] Google Sparsehashを使うときの注意点 - tsubosakaの日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/c541ea2500c0318fc6e5834b084376f4a70f360f/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127124028144%2F17680117127124030230%2F1557332439)
各種マップ実装の性能比較 - mixi engineer blog
今回は小ネタのmikioです。key/valueのレコードを高速に格納・参照・削除する仕組みが連想配列とかマップとか呼ばれて親しまれていますが、Tokyo Cabinetのオンメモリマップの性能をC++の各種実装と比較してみました。 以下の実装を対象として、100万レコードの格納と検索にかかる時間を計測します。キーと値は各8バイトの文字列とします。 Tokyo Cabientのオンメモリマップ（TCMAP） STL（C++の標準テンプレートライブラリ）のmapとmulti mapとset GNU拡張テンプレートのハッシュマップ Googleのdense hashおよびsparse hash テストコードはこちらに挙げておきます。具体的な操作としては、マップオブジェクトを生成し、バケット配列の要素数をレコード数と同じにチューニングし、ループを回してレコード群を格納します。なお、STLのマップ
PFIセミナー資料: 研究開発2009 - DO++
昨日ありました、PFIでのセミナーでの発表資料です。 研究開発のチームの紹介の後に、2009年サーベイした論文の中で面白かった論文を 機械学習、データ構造、画像処理で紹介してます 紹介した話は - Multi-class CW (Multi-class Confidence Weighted Learning,) - AROW (Adaptive Regularization Of Weight Vector) - Online-EM algorithm - 全備簡潔木 (Fully-functional Succinct Tree) - 圧縮連想配列 (compressed function) - PatchMatch です。 ＃資料中の簡潔木の表現方法のDFUDSの紹介でtxも使用と書いてあるのは、公開しているtxでは、 LOUDSのみをつかっていますので正確ではありませんでした。これ
連想配列の進化 - DO++
キーに対して値を結びつける連想配列は多くのアプリケーションの肝であり、コンパクトかつ高速な処理が可能な連想配列を追い求め日夜研究が進められています。 特に非常に巨大な連想配列を高速に処理するというのが重要な課題となっています。例えば、音声認識・文字認識・機械翻訳などで使われている言語モデルでは、非常に大量のN個の単語列の情報（特に頻度）を格納することが重要になります。 この場合、キーが単語列であり、値が単語列のコーパス中での頻度に対応します。 例えばGoogle N-gram Corpusからは数十億種類ものN-gramのキーとその頻度などが取得できます。これらを主記憶上に格納し、それに関する情報（頻度や特徴情報）を操作することが必要になります。 そのほかにも大規模なデータを扱う問題の多くが巨大な連想配列を必要とします。 ここではこのような連想配列の中でも、キーの情報を格納することすら難し
Succinct なトライの実験に用いたソースコード - やた＠はてな日記
いつものように，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/）をコピーすれば使えます． トライを構築する手順は，以下のようになっています． 基礎となる
C言語でハッシュテーブルを実装してしまった〜高速化編〜 - へぼいいいわけ
2ちゃんねるのdatを高速で処理するプログラムを書いていたら、いつのまにかC言語でハッシュテーブルを実装してしまい、(結構ブクマされたので)そっちばかり頑張って、結局２ちゃんねるのdatを高速で処理するプログラムは書けていません。 ちなみに、名前は「unhash」です。 動きなどの細かいことは、前回のC言語でハッシュテーブルを実装してしまったを参照ください。 今回、高速化に取り組んだことで前回に比べ最大4.15倍の速度で動作するようになりました。 その他、Hash衝突率の低下、ランダムアクセス機能の追加等、細かいところで実用性が向上しています。 前回はライセンスも糞もありませんでしたが、MITライセンスとして配布することにしました。 高速化した最新版のダウンロードはこちらです。 http://www.heiwaboke.net/lang-c/src/unhash/unhash-0.05.t
はてなブログ | 無料ブログを作成しよう
思いは言葉に。 はてなブログは、あなたの思いや考えを残したり、 さまざまな人が綴った多様な価値観に触れたりできる場所です。
Binary Indexed Tree (Fenwick Tree) - naoyaのはてなダイアリー
圧縮アルゴリズムにおける適応型算術符号の実装では、累積頻度表を効率的に更新できるデータ構造が必要になります。もともと算術符号を実装するには累積頻度表が必要なのですが、これが適応型になると、記号列を先頭から符号化しながら、すでに見た記号の累積頻度を更新していく必要があるためです。 累積度数表をナイーブに実装すると、更新には O(n) かかってしまいます。配列で表を持っていた場合、適当な要素の頻度に更新がかかるとその要素よりも前の要素すべてを更新する必要があります。適応型算術符号のように記号を符号化する度に更新がかかるケースには向いていません。 Binary Indexed Tree (BIT, P.Fenwick 氏の名前を取って Fenwick Tree と呼ばれることもあるようです) を使うと、累積頻度表を更新 O(lg n)、参照 O(lg n) で実現することができます。BIT は更
String::Dictionary - naoyaのはてなダイアリー
String::Dictionary という Perl のライブラリを作ってみました。 http://github.com/naoya/perl-String-Dictionary/tree/master String::Dictionary は検索エンジンその他を作る時に必要になる「辞書」のためのデータ構造 + API です。辞書は単語の集まりですが、これを配列やハッシュなどで持つのではなく、単語をすべて繋げた一つの大きな文字列として保持することでメモリ領域を節約したものです。単語は単に文字列連結で持つだけでなく、Front Coding で圧縮しています。以下簡単な解説です。 辞書は例えば [0] ･･･ jezebel [1] ･･･ jezer [2] ･･･ jezerit [3] ･･･ jeziah [4] ･･･ jeziel ...という風に単語を配列で持つことで実現でき
kd木 - Wikipedia
3次元のkd木。根セル（白）をまず2つの部分セルに分割（赤）し、それぞれをさらに2つに分割（緑）している。最後に4つのセルそれぞれを2つに分割（青）している。それ以上の分割はされていないので、最終的にできた8つのセルを葉セルと呼ぶ。黄色の球は木の頂点を表している。 kd木（英: kd-tree, k-dimensional tree）は、k次元のユークリッド空間にある点を分類する空間分割データ構造である。kd木は、多次元探索鍵を使った探索（例えば、範囲探索や最近傍探索）などの用途に使われるデータ構造である。kd木はBSP木の特殊ケースである。 kd木は、座標軸の1つに垂直な平面だけを使って分割を行う。BSP木では分割平面の角度は任意である。さらに一般的には、kd木の根ノードから葉ノードまでの各ノードには1つの点が格納される[1]。この点もBSP木とは異なり、BSP木では葉ノードのみが点（ま
過去の状態のスナップショットを取れるMap - 2009-04-24 - きしだのはてな
時間を指定して、その時点での状態を取れるようなMapを作ってみた。 何に使うかとかは考えてない。 こういった、データの世代別管理をして過去のある時点をスナップショットとして取得できるようなデータ構造は、扱うデータが巨大になってバックアップのためにシステムを止めれないというときに重要になったりしますね。 あと、データを変更せず追記する一方なので、ストレージの仕組みとして使うと、変更回数の制限があるSSDと相性がいいとか。 使うとこんな感じ。 public static void main(String[] args) throws InterruptedException{ VersionedMap<String, Integer> vm = new VersionedMap<String, Integer>(); vm.put("abc", 3); vm.put("aaa", 6); vm
B-Tree - アルゴリズム・イントロダクション 18章 - ninjinkun's diary
アルゴリズム・イントロダクション勉強会，B-Treeの章を担当しましたので，資料を公開いたします． Algorithm Introduction #18 B-Tree View more presentations from ninjinkun. B-Treeはデータ容量が主記憶に収まらないような場合に有効なデータ構造で，MySQLなどのDBや，最新のファイルシステムのインデックスとして用いられています．（MySQLはインデックス管理の方式を選択可能） 主に以下の利点があります． ノードの大きさをページサイズに最適化できる ページの読み込みがディスクアクセスに最適化される ページの読み込み数を木の高さhに抑えられる ディスクへのアクセス回数を抑えることができる id:naoyaのブログも参考になります． B木 - naoyaのはてなダイアリー 当日の発表はテンパってしまい，アレな感じになっ
B木 - naoyaのはてなダイアリー
昨年から続いているアルゴリズムイントロダクション輪講も、早いもので次は18章です。18章のテーマはB木(B Tree, Bツリー) です。B木はマルチウェイ平衡木(多分木による平衡木)で、データベースやファイルシステムなどでも良く使われる重要なデータ構造です。B木は一つの木の頂点にぶら下がる枝の本数の下限と上限を設けた上、常に平衡木であることを制約としたデータ構造になります。 輪講の予習がてら、B木を Python で実装してみました。ソースコードを最後に掲載します。以下は B木に関する考察です。 B木がなぜ重要なのか B木が重要なのは、B木(の変種であるB+木*1など)が二次記憶装置上で効率良く操作できるように設計されたデータ構造だからです。データベースを利用するウェブアプリケーションなど、二次記憶(ハードディスク)上の大量のデータを扱うソフトウェアを運用した経験がある方なら、いかにディ
DO++ : 透過的データ圧縮
可逆データ圧縮分野で、現在研究が盛んな分野の一つが、データを圧縮した状態のまま定数時間でランダムアクセスをサポートするデータ圧縮方式です（word RAMモデルでO(log n)サイズの復元が定数時間)。 これは、データをあたかも圧縮していないかのように扱えるため、透過的データ圧縮/構造と呼ばれています（英語だとまだ決まってない？)。 例えば1GBのデータを圧縮した状態で、途中300MB目から4Byteだけ復元しようというのが定数時間で実現できるわけです。これは理論的にもかなり強いことをいっていて，例えば今あるデータ構造やアルゴリズムが、O(T)時間である問題を解けるというのがあったら、それを全く同じO(T)時間のままデータ構造を圧縮し作業領域量を減らすことができます (一応データ構造に対し読み込み操作しか無い場合。書き込みもある場合はまたちょっと面倒になる） このデータを圧縮したまま扱う
Red–black tree - Wikipedia
In computer science, a red–black tree is a self-balancing binary search tree data structure noted for fast storage and retrieval of ordered information. The nodes in a red-black tree hold an extra "color" bit, often drawn as red and black, which help ensure that the tree is always approximately balanced.[1] When the tree is modified, the new tree is rearranged and "repainted" to restore the colori
Skip Lists
Skip Lists は 1990年に William Pugh によって開発されたリスト構造体の一種である。 オリジナルの論文は William Pugh, "Skip Lists: A Probablistic Alternative to Balanced Trees", Communications of the ACM, June 1990 となっている。 この論文は ftp://ftp.cs.umd.edu/pub/skipLists/skiplists.pdf からコピーを入手可能である。 また、Unix Magazine 1999年 1月号 を入手できれば、 そこには日本語で書かれた解説があるが、 これはほとんど論文丸写しに近いので、きっと重宝するだろう。 数多くの、要素が増減しなおかつ入れ替わるようなデータ構造で、 さらにランダムアクセスが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
String Data Structures and Algorithms --- Dr. Nikolas Askitis
サービス終了のお知らせ