テキスト圧縮はこれ一冊でOK！？な優良書籍「The Burrows-Wheeler Transform」を読んだ - EchizenBlog-Zwei
以前より気になっていた書籍「The Burrows-Wheeler Transform Data Compression, Suffix Arrays, and Pattern matching」を読む機会を得ることができた。それなりに高額な本だったので購入が躊躇っていたのだけど、これは自分用に購入してもいいかも。というくらいの良書だったので紹介しておく。 本書はタイトルのとおりBWT(Burrows-Wheeler変換)に関する書籍。サブタイトルにあるようにデータ圧縮やSuffixArrayによる全文検索についても充実した内容になっている。最後のPattern matchingはテキストから検索キーとexactにマッチした、もしくは類似した箇所を取り出すよ、という話。2008年の本なので比較的新しい話題も扱っていて満足度が高い。 また本書の特色は圧縮ありきで始まり、そこから全文検索可能な
物理エンジンライブラリ Box2DFlashAS3 衝突判定と衝突のグループ・カテゴリ分け | hokori.net
public class StudyB2Contact extends B2Base { public function StudyB2Contact() { makeB2Walls(); makeGroup(); this.addEventListener(Event.ENTER_FRAME, update, false, 0, true); //マウスジョイント用 this.addEventListener(MouseEvent.MOUSE_DOWN, this.onMouseDown, false, 0, true); this.addEventListener(MouseEvent.MOUSE_UP, this.onMouseUp, false, 0, true); } //Box2D 上下左右の壁作成 private function makeB2Walls():void { /
Wavelet Tree - naoyaのはてなダイアリー
圧縮全文索引の実装などでしばしば利用される Rank/Select 辞書と呼ばれるデータ構造があります。詳しくは参考文献を参照していただくとして、今回は一般の文字列に対して効率的に Rank/Select を可能とするデータ構造である Wavelet Tree (ウェーブレット木) のライブラリを作りました。 http://github.com/naoya/perl-algorithm-wavelettree/tree/master my $wt = Algorithm::WaveletTree->new("abccbbabca"); is $wt->rank(6, 'a'), 2; is $wt->rank(6, 'b'), 3; is $wt->rank(9, 'b'), 4; is $wt->select(0, 'a'), 0; is $wt->select(1, 'a'), 6;
巡回セールスマン問題 - Wikipedia
英語版記事を日本語へ機械翻訳したバージョン（Google翻訳）。 万が一翻訳の手がかりとして機械翻訳を用いた場合、翻訳者は必ず翻訳元原文を参照して機械翻訳の誤りを訂正し、正確な翻訳にしなければなりません。これが成されていない場合、記事は削除の方針G-3に基づき、削除される可能性があります。 信頼性が低いまたは低品質な文章を翻訳しないでください。もし可能ならば、文章を他言語版記事に示された文献で正しいかどうかを確認してください。 履歴継承を行うため、要約欄に翻訳元となった記事のページ名・版について記述する必要があります。記述方法については、Wikipedia:翻訳のガイドライン#要約欄への記入を参照ください。 翻訳後、{{翻訳告知|en|Travelling salesman problem|…}}をノートに追加することもできます。 Wikipedia:翻訳のガイドラインに、より詳細な翻訳の
大規模データで単語の数を数える - ny23の日記
大規模データから one-pass で item（n-gram など）の頻度を数える手法に関するメモ．ここ数年，毎年のように超大規模な n-gram の統計情報を空間／時間効率良く利用するための手法が提案されている．最近だと， Storing the Web in Memory: Space Efficient Language Models with Constant Time Retrieval (EMNLP 2010) とか．この論文では，最小完全ハッシュ関数や power-law を考慮した頻度表現の圧縮など，細かい技術を丁寧に組み上げており，これぐらい工夫が細かくなってくるとlog-frequency Bloom filter (ACL 2007) ぐらいからから始まった n-gram 頻度情報の圧縮の研究もそろそろ収束したかという印象（ちょうど論文を読む直前に，この論文の7節の
分散ストレージに使えるかもしれないアルゴリズム
The document discusses EpiChord, an enhancement of the Chord distributed hash table. It presents EpiChord's lookup algorithm and its division of the address space to reduce routing table sizes while maintaining low diameter. Bloom filters are also summarized, including how they represent sets using bit vectors and can check for set membership with possible false positives. Techniques like vector c
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月号 を入手できれば、 そこには日本語で書かれた解説があるが、 これはほとんど論文丸写しに近いので、きっと重宝するだろう。 数多くの、要素が増減しなおかつ入れ替わるようなデータ構造で、 さらにランダムアクセスが
INTEL コード & ダウンロード
Using Intel.com Search You can easily search the entire Intel.com site in several ways. Brand Name: Core i9 Document Number: 123456 Code Name: Emerald Rapids Special Operators: “Ice Lake”, Ice AND Lake, Ice OR Lake, Ice* Quick Links You can also try the quick links below to see results for most popular searches. Product Information Support Drivers & Software
開発メモ: トップNソートの検討
上位N件をソートした状態で取り出すという、いわゆる「トップNソート」の効率的な実装について検討してみた。 背景 データベースに対して、ある順序でソートした時の最初の何件かが欲しいというクエリを投げることはよくあるだろう。SNSで言えば、誰かのコンテンツの最新10件を表示するとかいう場合だ。SQLだと "ORDER BY xxx LIMIT yyy" とかいう感じ。同じような操作は全文検索システムのスコアリングでも定番である。俺もよく自分で実装するわけだが、その度に適当な試行錯誤をして時間がもったいないので、今回は入念に調べて決定版を出そうじゃないか。 全体をソートして上位を取り出せば目的は満たせるのだが、それだと無駄な計算が多い。100万件の中から上位10件だけ欲しい場合に、残りの99万9990件まで律儀にソートする必要はない。ということで、上位N件をソートして取り出すという「トップNソー
開発メモ: オンメモリB+木による省メモリ連想配列
Kyoto Cabinet 1.2.2から加わったGrassDBは、オンメモリでページ管理を行うB+木を実装してメモリを節約しちゃう仕組みである。それを使ってJava、Python、Ruby、Perlなどのハッシュ（連想配列）機構を鬼のように省メモリにしてみる。頑張ればなんと20分の1になる。 前提 B木やその変種のB+木などは、キーの順序が近いレコード群を「ページ」という単位にまとめてシリアライズしてストレージに書き込むことで、入出力の頻度を減らして高速化することを意図している。メモリに比べて低速なストレージの上で大量のデータを管理するために使われる。多くのRDBMSやいくつかのDBMがB+木をサポートしているのはそれが理由であろう。一方で、メモリ上で検索可能なデータ構造を表現するためには、二分探索木やその特殊例である赤黒木が使われる。STLのstd::mapの実装にも赤黒木を使うのが一
Bloom filterの説明 — ありえるえりあ
Bloom filterの説明 以前、bloom filterに言及したことがあるのですが、実は、言及しただけで何も調べていませんでした。 来週、ある人の話を聞く時、知らないとついていけない可能性があるので、調べてみました。 - 参考サイト 感想ですが、予想以上にシンプルでした。 動作イメージ(だけ)は誰でもイメージできます(実装も簡単)。 上の参考サイトも、英語に気後れせず、図だけでも見てください。動作は想像できるはずです。そして、たぶん、その想像は当たっています。 参考サイトを読めば分かることを日本語で改めて説明するのも気がひけますが、どうしても英語を読みたくない人のために、簡単に説明してみます。 動作イメージ あ る入力文書が与えられたとして、後で、その文書に、ある単語fooが存在するかを高速にチェックしたい、という問題を想定するのが理解しやすいと思いま す。入力文書に対する前処理を
PageRankアルゴリズムの大規模実装における注意事項 - SELECT * FROM life;
PythonPageRankを求めるのにべき乗法が用いられることが多いですが、工夫をしないと大きなグラフに対してPageRankを求めることは難しくなります。今回は、素直な実装法が持つ問題を解説しつつ、PageRankの大規模実装する方法について書いてみようと思います。注意PageRank自体に対するある程度の知識が前提となります。PageRankに詳しくない人は、まず先にページランク - Wikipediaなどを軽く読んでみるといいかも知れません。導入PageRankと言えばGoogle検索のランキングアルゴリズムとして有名ですね。PageRankを直感的に説明するとリンク元ページのPageRank値が高いほど、リンクされているページのPageRank値は高くなるとなるのは有名ですが、数学的にはGoogle行列の主固有ベクトルがPageRankベクトルであると言うことができます。Goog
Google Code Jam 2010 Round2 感想 - 科学と非科学の迷宮
撃沈。10点だけとって1550/3000位。日本人では89位だったようです。 ソースコードはこちら。 とりあえず目標のRound 2 出場は果たしたし、満足です。 ……といいつつも、やっぱり欲が膨らんでしまうのが人間。 ボーダーラインの31点は、もうちょっと頑張れば手が届きそうな気がしました。 来年は Round 3 出場を目指したいですね。 2ヶ月前、私には python の知識もプログラミングコンテストの知識もほぼ皆無でした。 1ヶ月前、python は少し書けるようになりましたが、Round 1 の問題はまだ私には難問でした(今も簡単だとは思ってませんが)。 そして今、Round 2 の解説を見て理解できる程度には競技プログラミングのことを理解し、好きな言語でコーディングしろと言われて一番に出てくるのが python になりました。*1 人なんて2ヶ月あれば変われるもの、というのをあ
2010-06-15
Google App Engineで何かと話題になってたランキング問題。 appengine ja night #8(ajn8)に参加された方ならご存知のように、既にid:koherentさんがSkiplistというアルゴリズムを使って解決しています。 参考：http://d.hatena.ne.jp/koherent/20100425/1272176872 そのほかにも、id:bufferingsさんの実装例もあります。 参考：http://d.hatena.ne.jp/bufferings/20100225/1267121912 id:bufferingsさんのとほぼ同じアイデアを自分でも思いついてたんで、ちょっとslim3使って実装してみました。 http://tetz-lab.appspot.com/ranking/ 事前に乱数で10万件の点数データを入れてあります。 って、何を今
d.y.d. 2倍だけじゃない
10:01 10/07/20 それでも２倍だ 先日のvectorの伸長度合いの記事に関して 本当に1.5倍のほうがメモリ効率がよいのか という反応をいただきました。とても興味深い。みんな読みましょう。 自分の理解メモ： 「再利用ができるから嬉しい」等の議論をするなら、 今までに確保したメモリ (1 + r^1 + ... + r^k) のうち、 有効に使えてるメモリ r^{k-1} (バッファ拡大直後) や r^k (次のバッファ拡大直前) の割合で評価してみようじゃないかという。 まず簡単のために再利用をしない場合を考えると、この割合はそれぞれ (r-1)/r^2、 (r-1)/r になります（途中計算略）。 この利用率が最悪になる瞬間 (r-1)/r^2 を最善にしよう、 という一つの指標で考えてみると、式を微分なりなんなりしてみると r = 2 で最大(25%)となることがわかります
プログラミングコンテストでの動的計画法
2. はじめに • 「動的計画法」は英語で 「Dynamic Programming」 と言います． • 略して「DP」とよく呼ばれます． • スライドでも以後使います． 4. ナップサック問題とは？ • n 個の品物がある • 品物 i は重さ wi, 価値 vi • 重さの合計が U を超えないように選ぶ – 1 つの品物は 1 つまで • この時の価値の合計の最大値は？ 品物 1 品物 2 品物 n 重さ w1 重さ w2 ・・・ 重さ wn 価値 v1 価値 v2 価値 vn 5. ナップサック問題の例 品物 1 品物 2 品物 3 品物 4 U=5 w1 = 2 w2 = 1 w3 = 3 w4 = 2 v1 = 3 v2 = 2 v3 = 4 v4 = 2 品物 1 品物 2 品物 3 品物 4 答え 7 w1 = 2 w2 = 1 w3 = 3 w4 = 2 v1 = 3 v
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スプライト - PukiWiki
From Concurrent to Parallel
Java theory and practice: Stick a fork in it
プログラミングコンテストでのデータ構造
