単語と文字の話 - Preferred Networks Research & Development
4月からPFIで働いてます。海野です。 今日は単語の話をします。読み物的な話なので軽く読んでください。 テキストデータなどの自然文を機械処理するときには、まず最初に単語に分割するということをよく行います。一般的にはMeCabやChasenといった形態素解析エンジンに投げて行います。形態素と単語の区別という話もあるのですが、ここでは大雑把に「連続した文字列の単位」くらいの意味で話します。 検索という文脈ですと形態素インデックスという言葉がありますが、これは検索の最小単位を文字単位ではなくて形態素の単位にするということです。例えば「東京都」は「東京」「都」に分かれるため、「京都」というクエリに対して見つかるのを防ぐなど、精度を上げる効果があります。反面、深刻な検索漏れを引き起こす可能性があるため嫌われることが多いです。こうした漏れは検索に限らず、テキストマイニングなどの文脈でも問題となることが
diffの動作原理を知る～どのようにして差分を導き出すのか | gihyo.jp
UNIXの基本的なコマンドの1つであるdiff。 これに実装されているアルゴリズムは実に興味深い世界が広がっています。 本稿では、筆者が開発した独自ライブラリ「dtl」をもとに「diffのしくみ」を解説します。 はじめに diffは2つのファイルやディレクトリの差分を取るのに使用するプログラムです。 ソフトウェア開発を行っている方であれば、SubversionやGitなどのバージョン管理システムを通して利用していることが多いかと思います。本稿ではそのdiffの動作原理について解説します。 差分の計算の際に重要な3つの要素 差分を計算するというのは次の3つを計算することに帰結します。 編集距離 2つの要素列の違いを数値化したもの LCS（Longest Common Subsequence） 2つの要素列の最長共通部分列 SES（Shortest Edit Script） ある要素列を別の要
「言語処理のための機械学習入門」を参考に各種モデルに対するEMアルゴリズムを実装したよ - nokunoの日記
Amazonにもレビューを書いたのですが、高村さんの「言語処理のための機械学習入門」を読みました。実はこの本を読むのは2回目で、1回目はドラフト版のレビューをさせていただく機会があったのですが、そのときは「言語処理研究者のための機械学習入門」というタイトルで、ちょっと敷居が高いのではないかとコメントしたら「研究者」の部分が削られたという経緯があったりしました。 それはともかくとして、以前読んだときは時間もなくて実装までする暇はなかったのですが、今度はもうちょっとじっくり読みたいなということで、このブログに書いてみようと思います。EMアルゴリズムは教師なし学習を確率モデルと最尤推定でやろうとするときに必ず出てくる手法で、隠れ変数や欠損値を含む色々なモデルに適用できる汎用的なフレームワークになっています。一般的には混合ガウス分布の場合をまず説明して、それがk-means法の一般化した形になって
Perceptron を手で計算して理解してみる (nakatani @ cybozu labs)
Perceptron の実装とか見ると、ものすごく簡単なので、本当にこれで学習できちゃうの？ と不安になってしまいました(苦笑)。 こういうときは、実際にパーセプトロンが計算しているとおりに、紙と鉛筆で計算してみて、期待する結果が出てくることを確認してみたくなります。 参照する教科書は「パターン認識と機械学習・上」(PRML) の「 4.1.7 パーセプトロンアルゴリズム」。 短い節です。必要最低限のことを一通り書いてある感じかな。 計算に用いるサンプルですが、手で計算できる規模でないといけないので、論理演算の AND を試してみることにします。 簡単に勉強 ちゃんとした説明は PRML などを見て欲しいですが、とても簡単にまとめます。 ２値の線形識別モデルは、N 次元空間内を (N-1) 次元の超平面(決定面)で分割することで、入力ベクトル x から得られる特徴ベクトル φ(x) が２つ
yebo blog: クヌース教授は間違っていた
2010/06/15 クヌース教授は間違っていた Slashdotによれば、この数十年間、クヌース教授をはじめとするコンピュータ科学者が最適としてきたアルゴリズムを10倍高速にする方法をPoul-Henning Kamp (PHK) というハッカーが見付けたという。その論文タイトルは「You're Doing It Wrong (あなた達のやっている事は間違っている)」で、ACM Queueに掲載されている。別にクヌース教授の考えが間違っているわけではなく、アルゴリズム的には正しいが、実用レベルでは、OSには仮想メモリがあり、VMと干渉しないようにすれば簡単に高性能なシステムが作れる。従来の考え方はモダンな計算機を考慮に入れていないので、現実的には不適合を起こしている。具体的にはヒープにBツリーの要素を取り込んだBヒープというデータ構造を使うことで、バイナリヒープの10倍のパフォーマンスを
fujimap: 簡潔な連想配列 - DO++
博論終わったので仕事の合間にfujimapというライブラリを作ってみました。 fujimap project fujimapは作業領域が非常に小さい連想配列で、文字列からなるKeyを利用して、整数値もしくは文字列からなるValueを登録・参照することができるライブラリです。 今巷では大規模なKey Value Stroe (KVS)が流行っていますがFujimapは一台のマシンのメモリ上で動作することを想定して作成されています．Fujimapの特徴は必要な作業領域量が非常に小さいことです．キー自体を明示的に保存しないため、作業領域は値を格納するのに必要なサイズと、許容するfalse positive（後述）にのみ依存します。 例えば、google N-gramのunigramの約1300万キーワードとそれらの頻度の対数を記録する場合、false positiveを気にしないなら、一キーワー
無限ストリームで幅優先探索 - keigoiの日記
参考：http://d.hatena.ne.jp/yoshihiro503/20100119#p1 証明すげー。 あと、幅優先探索で見つけたパスを無限ストリームで並べているのを見てこれは面白いと思った。枝刈り付きBFSとゴールの発見手続きを独立に書けているのか。なるほど！ ストリームを使ったプログラミングはHaskellでもよくあるし、モジュール性を向上させるというのもどこかで読んだけど、実際に目の当たりにするととても面白い。そしてストリームで書いたことによるプログラムの独立性が証明の簡潔さにつながっている(たぶん)のはとても興味深い。いや私はアルゴリズム苦手だし、関数型プログラムでパズルを解く人たちにはストリームなんて当然のことなのかもしれない。でもとにかく、感銘を受けたのでちょっとアルゴリズムを勉強しなおそうと思った。プログラムのエレガントさは、きっと証明のしやすさに影響するのだ。 一
迷路の試験問題を解いてみた - にわとり小屋でのプログラミング
参考：人材獲得作戦・４ 試験問題ほか: 人生を書き換える者すらいた。 Lv4に評価されるためには、最短性の完全なチェックが必要だったのでCoqで証明してみた。 まず、accessiblesという関数を定義し、以下の性質を証明した。 ここでplengthはパスの長さを計る関数で、Path x pはpがxを起点としたパスであるという述語。endofはパスの終点を求める関数。 Fixpoint accessibles (start : node) (len : nat) : list path := match len with | O => (PUnit start) :: nil | S n' => div_equiv path_equiv_dec @@ (flat_map expand @@ accessibles start n') end. この関数はstartから始まってlenの長さ
プログラム・プロムナード
会誌「情報処理」連載の「プログラム・プロムナード」（2002年4月〜2005年3月掲載）と「Haskellプログラミング」（2005年4月〜2006年3月掲載）はどなたでもご覧になれます。ファイルはすべてPDF形式です。 「Haskellプログラミング」に掲載されたプログラムは http://www.sampou.org/haskell/ipsj/ から取ることができます.
経路探索アルゴリズムの「ダイクストラ法」と「A*」をビジュアライズしてみた - てっく煮ブログ
as詳解 ActionScript 3.0アニメーション ―衝突判定・AI・3DからピクセルシェーダまでFlash上級テクニック を読んでいて、経路探索のアルゴリズムで A* が取り上げられていました。A* については、いろいろ検索して調べたりもしたのですが、やっぱり本に書いてあると理解しやすいですね。せっかくなので自分流に実装してビジュアライズしてみました。ダイクストラ法まずは A* の特別なケースでもあるダイクストラ法から見ていきます。クリックすると探索のシミュレーションが開始します。スタート地点(S)からゴール(G)への探索が始まります。色がついたところが「最短経路が決定した場所」です。スタート地点から少しずつ探索が完了していきます。半分ぐらい完了しました。まだまだ進みます。最後まで終わりました。最短経路を黒色矢印で表示しています。ダイクストラ法は、スタート地点から近いノード(=マス
Web上の膨大な画像に基づく自動画像補完技術の威力 - A Successful Failure
画像内に映り込んだ所望のオブジェクトを排除し、違和感の無い画像を生成するシーン補完技術に関しては近年複数の研究成果が発表されている。しかし中でも2007年のSIGGRAPHにて米カーネギメロン大のJames HaysとAlexei A. Efrosが発表した手法*1はブレークスルーとなりうる画期的なものだ。 論より証拠、早速適用例を見てみよう。本エントリで利用する画像はPresentationからの引用である。元画像の中から邪魔なオブジェクト等の隠蔽すべき領域を指定すると、その領域が補完された画像が自動的に生成される。 アルゴリズム 効果は抜群だがアイデア自体は単純なものだ。Web上には莫大な数量の画像がアップされており、今や対象となる画像の類似画像を一瞬にして大量に検索することができる。そこで、検索された類似画像で隠蔽領域を完全に置き換えてしまうことで違和感の無い補完画像を生成するのだ。
統計的に正しいランキングを行う方法をJavaで書く - バイオインフォマティクスって何ですか？
Java | 統計的に正しいランキングを行う方法を見たのでちょっとJavaで書いてみる。はじめになにがしたいかというと、「レイティング」というのをご存じでしょうか。Amazonとかで商品を購入者が星つけて評価したりしてるやつ。ああいうので「良かったランキング」というのを作りたい。みんなが「購入して良かった」という評価をつけてる商品は、他の人にとっても「良かった商品」になる可能性が高い。いい商品だということがわかるわけです。問題点じゃあどういうふうにランキングをつければいいの？ということを考えると、次の問題にぶちあたる。評価してる人の数の違い。例えば、Aという商品は100人が評価していて、平均の星の数は 4.8 だとする。一方、Bの商品は1人が星5つで評価していたとする。このとき、Aの商品とBの商品ではどちらをランキング上位にすればいいだろうか？あなたならどちらを買いたい？Aはたくさんの人が
B木 - naoyaのはてなダイアリー
昨年から続いているアルゴリズムイントロダクション輪講も、早いもので次は18章です。18章のテーマはB木(B Tree, Bツリー) です。B木はマルチウェイ平衡木(多分木による平衡木)で、データベースやファイルシステムなどでも良く使われる重要なデータ構造です。B木は一つの木の頂点にぶら下がる枝の本数の下限と上限を設けた上、常に平衡木であることを制約としたデータ構造になります。 輪講の予習がてら、B木を Python で実装してみました。ソースコードを最後に掲載します。以下は B木に関する考察です。 B木がなぜ重要なのか B木が重要なのは、B木(の変種であるB+木*1など)が二次記憶装置上で効率良く操作できるように設計されたデータ構造だからです。データベースを利用するウェブアプリケーションなど、二次記憶(ハードディスク)上の大量のデータを扱うソフトウェアを運用した経験がある方なら、いかにディ
Aho Corasick 法 - naoyaのはてなダイアリー
適当な単語群を含む辞書があったとします。「京都の高倉二条に美味しいつけ麺のお店がある」*1という文章が入力として与えられたとき、この文章中に含まれる辞書中のキーワードを抽出したい、ということがあります。例えば辞書に「京都」「高倉二条」「つけ麺」「店」という単語が含まれていた場合には、これらの単語(と出現位置)が入力に対しての出力になります。 この類の処理は、任意の開始位置から部分一致する辞書中のキーワードをすべて取り出す処理、ということで「共通接頭辞検索 (Common Prefix Search)」などと呼ばれるそうです。形態素解析、Wikipedia やはてなキーワードのキーワードリンク処理などが代表的な応用例です。 Aho Corasick 法 任意のテキストから辞書に含まれるキーワードをすべて抽出するという処理の実現方法は色々とあります。Aho Corasick 法はその方法のひと
編集距離 (Levenshtein Distance) - naoyaのはてなダイアリー
昨日 最長共通部分列問題 (LCS) について触れました。ついでなので編集距離のアルゴリズムについても整理してみます。 編集距離 (レーベンシュタイン距離, Levenshtein Distance) は二つの文字列の類似度 (異なり具合) を定量化するための数値です。文字の挿入/削除/置換で一方を他方に変形するための最小手順回数を数えたものが編集距離です。 例えば 伊藤直哉と伊藤直也 … 編集距離 1 伊藤直と伊藤直也 … 編集距離 1 佐藤直哉と伊藤直也 … 編集距離 2 佐藤B作と伊藤直也 … 編集距離 3 という具合です。 編集距離はスペルミスを修正するプログラムや、近似文字列照合 (検索対象の文書から入力文字にある程度近い部分文字列を探し出す全文検索) などで利用されます。 編集距離算出は動的計画法 (Dynamic Programming, DP) で計算することができることが
Life is beautiful: 恋の連立方程式、「パートナー探し」の最適化アルゴリズムに関する一考察
「自分にできるだけ相応（ふさわ）しいパートナー」を見つけることは、我々人間にとって、人生の最も重要なのテーマの一つでもある。しかし、そのプロセスである「恋愛」や「お見合い」に関して、なぜか今までシステマティックな考察がされて来なかったように思える。そこで、今回はその「パートナー探し」のプロセスをモデル化・数値化することにより、最適なアルゴリズムを見つけようと思う。 まずは、「自分にできるだけ相応しいパートナーを探す」というあいまいな問題を、もう少し明確にモデル化された問題に単純化する。もちろん、単純化するとはいえ、あまり現実とかけ離れていては役に立たないので、現実味を壊さない程度の単純化を行う。 ［モデル化された問題］ 結婚適齢期の女性が、これから１０人の男性と順番にお見合いをして、その中から結婚相手を見つけることにしたとする。相手の意思は無視して良く、「この人と結婚したい」と宣言した時点
IBM - 日本
企業には、汎用的なAIではなく「ビジネス向けに設計されたAI」が求められることを強調する、新たなキャンペーンを開始しました。これらのアニメーションに込めた「IBMよりお伝えしたい5つのこと」をご紹介します。 最新情報 IBM、2025年度第2四半期の連結決算を発表 日本IBM、医療従事者の業務変革を促進する「病院業務支援AIソリューション」を提供開始 CEOスタディ2025「ビジネス成長を飛躍させるための5つの意識改革」日本語版を公開 IBM、エンタープライズITの水準を引き上げるIBM Power11を発表 ウィンブルドンを主催するオールイングランド・ローンテニス・クラブとIBM、リアルタイムでファン・エンゲージメントを高める新たなAI機能を発表 日本IBM、JICAの海外投融資（融資）業務のシステム構築を支援 IBMと理化学研究所、米国外で初となるIBM Quantum System
404 Blog Not Found:プログラマーでなくても名前ぐらい覚えておきたいアルゴリズムx10
2007年11月26日18:15 カテゴリMathLightweight Languages プログラマーでなくても名前ぐらい覚えておきたいアルゴリズムx10 ぎくっ あなたが一番好きなアルゴリズムを教えてください。 また、その理由やどんな点が好きなのかも教えてください。 - 人力検索はてな なぜぎくってしているかというと、実はすでにアルゴリズム本の発注を受けているからなのだ。いつまでも伏せておくのもなんなので、ここにえいやっとdiscloseしてしまうことにする。 アルゴリズム大募集! C&R研究所 - トップページ その下書きもかねて、そこでも紹介しないわけに行かないメジャーなアルゴリズムをとりあえず10個紹介しておくことにする。 ユークリッドの互除法(Euclidean algorithm) その昔(数百年ほど前)は「アルゴリズム」といえば、「手順一般」を指すのではなく、この「互除法
スペル修正プログラムはどう書くか
Peter Norvig / 青木靖 訳 先週、2人の友人(ディーンとビル)がそれぞれ別個にGoogleが極めて早く正確にスペル修正できるのには驚くばかりだと私に言った。たとえば speling のような語でGoogleを検索すると、0.1秒くらいで答えが返ってきて、もしかして: spelling じゃないかと言ってくる(YahooやMicrosoftのものにも同様の機能がある)。ディーンとビルが高い実績を持ったエンジニアであり数学者であることを思えば、スペル修正のような統計的言語処理についてもっと知っていて良さそうなものなのにと私は驚いた。しかし彼らは知らなかった。よく考えてみれば、 別に彼らが知っているべき理由はないのだった。 間違っていたのは彼らの知識ではなく、私の仮定の方だ。 このことについてちゃんとした説明を書いておけば、彼らばかりでなく多くの人に有益かもしれない。Googleの
文字列ソーティング #2 - odz buffer
文字列ソーティングの速度比較にいくつかのアルゴリズムで Suffix Array を構築してみた。 対象データは 30 MBytes ほどの英文新聞記事データで、gcc 4.0 で -O2 でコンパイル。結果はこんな感じ。 algorithm time[sec] quicksort 97.33 multikey quicksort 63.66 merge sort 73.62 std::sort 90.30 std::stable_sort 76.61 む。クイックソートよりマージソートの方が速いし。マージのコストはたいしたことないのかな。 ちなみに、Suffix Array の構築に特化したアルゴリズムだとこんな感じ。 algoritm time[sec] two-stage sort 33.50 improved two-stage sort 17.30 skew algorithm
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
