朝の6時に起きてNL研 (情報処理学会自然言語処理研究会)。今回は山梨大学である。中央線で1本なので、とても近い。自宅からドアツードアで2時間かからない。 甲府に降りるのは初めて (車や電車で通過したことはある) で、弟が甲府で仕事をしていたときに一度遊びに行こうかと思っていたのだが、ついぞ機会がないまま弟は東京勤務に戻ったので、行くタイミングを逸していたのであった。 トークの中ではやはり daiti-m さんの話が抜群におもしろく、理学寄りのモチベーションながら工学的にも嬉しい手法の研究をする、という研究スタンスは素敵だなぁ、と改めて思う。deep learning に食指が動かないのも、パラメータの自由度や手法が多すぎて調整が難しそう、というのがあって、確かにやってみないとそういうノウハウが得られないのでやる意味はあると思うのだが、激しくチューニングをしないとベストなパフォーマンスが得

午前中、自然言語処理のプログラミングチュートリアル。今年は[twitter:@neubig]さんの作った資料を使わせてもらっている。首都大の学生は授業では基本的にCを使うので、Javaも使ったことがある程度だそうだが、スクリプト言語は使ったことがない、というわけで、Pythonの導入から入ってくれるのも親切である。 言語処理のプログラミング基礎を学ぶというコンセプトでは、東北大の言語処理100本ノックもあるのだが、@neubig さんのチュートリアルが優れているのは、プログラミングをしていると自然と言語処理の基本も身につけることができるという点で、これまで首都大では言語処理の授業がなかったそうなので、演習しつつ言語処理の基礎知識も解説する、ということができることである。 もちろん100本ノックは100本ノックで、自然言語処理でいかにも使いそうな小技をカバーしているので、これはこれで意味があ

本会議も3日目になると、だいたい来るべき人は揃った感じ。 (写真は本会議のメイン会場の入り口のパネル) ランチタイムにロビーを通りがかると Hisami さんが到着しており、[twitter:@zzzelch] さん [twitter:@taku910] さんらと談笑中。ワークショップのみに参加する人たちは今日くらいから来ているそうだ。@zzzelch さんも自分と同じ研究費に申請しているらしいことを知る。自分も面接まで残っただけで喜んでいる場合ではなく、本気でスライド作らないと。 お昼はそういうわけで Hisami さん、NTT の S 木さんという「2人の鈴木さん」と食べる。他の人 (国外の人) からよく混同される、というお話を聞いたり……。確かに国が同じで同じ名字だったら間違えそう (「鈴木」というのが日本でよくある名字だということは国外の人には分からないだろうし)。ちなみに自分は同

午前中最初のセッションが [twitter:@uchumik] さんの発表。[twitter:@neubig] さんが急遽頼まれた座長らしい (笑) 昨日も発表キャンセル (no show) が相次いでいたが、どうもやはり洪水の影響で来られなくなったり (飛行機は飛んでいても大学や会社の判断で来られなくなったり、迂回せざるをえなくなったり) しているようである。最初のセッションの1番目、Google の Marius Pasca も開始5分前までレジストレーションもしていなかったようで、ヒヤヒヤしたものだが、なんとか間に合って堂々と発表していた。さすが大物は違う。 @uchumik さんの発表も無事終了し、今回共著者で発表の際に同席できる人は全部任務完了。[twitter:@seijik42] くんの発表がワークショップ最終日に控えているのだが、出張の都合によりワークショップが終わる時間ま

写真は会場近くのコンビニ、セブンイレブン (チェンマイに至る所にある) で買ったサントリーの「DAKARA」の現地味。確かアセロラ味だったかと思うが、イチゴの絞り汁を限りなく薄くしたような味で微妙だった。 朝からオープニングセッション。朝食に行くと、松本先生と [twitter:@shirayu] くん、[twitter:@Wildkatze] くんがいたので同席させてもらう。NAIST 勢は結局全員無事着いたらしい。(自分以外全員バンコク経由だったが、遅延などもなかったそうで) 朝イチのセッションは中国の検索エンジン会社、百度の人の基調講演だったが、内部の技術的な話はほとんどなく、あまりおもしろくなかった。Web API を20,000ほど提供しているというのと、検索ボックスから入力するのと比べて API 経由でのアクセスが全体のアクセスの30%を占める、というような統計は興味深かったが

チェンマイ最終日。入力メソッドに関する世界初の国際ワークショップが開かれるということで、ちょっと嬉しい。[twitter:@zzzelch] さんと Hisami さんと朝ご飯。この朝ご飯も最後か……。 オープニングは Hisami さんがタイ語の説明をして、チェンマイをタイ語で書くとこうなるんだ、ということを初めて知る (笑) 午前最初の招待講演は、[twitter:@masui] さんのお話。デモがたくさんあり、楽しい。スライドも完全公開されている。ソフトウェアも全部ご自身で作ってらして (@zzzelch さんが質問で「こんなにたくさんのソフト、全部自分で書いているんですか?」と訊くと「自分で書く以外、誰が書くんですか?」と即答された)、こういう生活がしたいものである。週1日は会議で大学に行かないといけないし、あと2日は授業をしないといけないが、残りの4日 (平日2日) は好きなこと

金曜日で本会議が終了し、次に出るべきワークショップは日曜日なので、1日待機日。 朝ご飯をゆっくり食べてスライドでも作るか、とロビーに来ると、松本先生がいたのでしばし歓談。帰国後の研究の進め方について話したりなど。最近は学生の数に対してスタッフの数が少ないので、どのようにするかちょくちょく話しているのだが、話している通りに進んだ試しがないような…… 松本先生が帰ってから teruaki-o くんと話していると、[twitter:@tishida] さんが通りがかったので、しばし歓談。人工知能系の学会と自然言語処理系の学会の違い、それぞれどういうところがうまく回っていて、どういうところがよろしくないか、というようなお話をお伺いしたり。人工知能系の会議はどれも AAAI だとか IJCAI みたいなトップ会議を模倣し、プチ AAAI みたいなのが溢れるので、逆にみんな AAAI だとか IJCA

5時に日光で自然に目が覚めたので電話。前使っていたプリペイドの携帯を持ってきたので$30チャージして、かれこれ3時間くらい話していると思うのだが、まだなくならない。日本の携帯電話にかけて1分$0.15のレートなので、200分いけるようだ。 朝はベストペーパー・ペストスチューデントペーパー・ベストショートペーパーの3本のトーク。これらの論文が決まらないと会議のプログラムを確定できないので、早くプログラムを公開してほしい、といろんな人からせっつかれて困った、と (ACL のプログラム委員長) 松本先生がぼやいていたのだが、ベストペーパーの紹介を今日は松本先生がして、ベストペーパーを事前に発表する Pros and Cons というタイトルでしっかり「事前に決めるのは大変だった」と苦言を呈していた (笑)　副学長に加えてプログラミング委員長、なんだか今年松本先生は忙しそうな年である。 さてベスト

契約書を読んで印鑑を押したりする仕事。ようやくここまで来た〜。いろいろな意味で自分乙。 学生の学内プロジェクトの話を聞いたりなんだり。過去何チームかのチューターになったことがあるが、今年はスルーかな？　松本研からはけっこう出すみたいな感じだと聞いているが……。松本先生も週末から海外出張だし、学振の推薦書も書かないといけないみたいだし、大変そう。 会誌「情報処理」(情報処理学会のマガジン)で研究会推薦博士論文速報というのに選んでいただいたので、概要やポンチ絵(なぜあれをポンチ絵というのだろう)を用意していたところ、学生の方々から「小町さん去年の3月に博士号を取ったのにいまごろなんですか。全然速報じゃないですよね」と至極真っ当な指摘を受ける。確かに1年ずつずれている気がするのだが…… ジャーナルの査読が来たが、〆切がタイトだし、さすがにちょっと国際会議の査読と重なっていて大変なので、お断りする

昨日，CRFの更新式の導出を行ったけれど，@nokunoさんのご指摘で，僕が算数が出来ないことが世に広まったわけだけれど (誰も見てないから広まってないか)，普通の人が計算すれば昨晩の展開はもっとシンプルにできる．というわけで訂正版をアップすることにした． 元々僕の勘違いは，log(A+B) = logA + logBと展開していたミスによるものであり，log(A/B)=logA - logBは正しい． スタート地点からやり直す． は，log(分子) - log(分母)の形にできるので， となる．自分はここでlogをΣの中に入れてハマっていた． さて，こっからの微分は以前よりもっと簡単． 一項目は，そのままwが外れるだけだし，後ろの部分は対数の微分と合成関数の微分がわかっていれば一瞬で解ける． よって， はい終了． 昨日の式展開がどれだけ遠回りだったかということが一瞬でばれてしまう．べっ，

Hierechical Dirichlet Process(HDP, 階層ディリクレ過程) を実装するのに必要な式を導出しつつ、実装してみるお話。 参照するのはこちらの論文。 [Y.W.Teh, M.I.Jordan, M.J.Beal & D.M.Blei. JASA2006] Hierarchical Dirichlet Processes http://www.gatsby.ucl.ac.uk/~ywteh/research/npbayes/jasa2006.pdf しかし全部拾っていくのは大変なので、ちょびっとずつ小分けに、かつ他の方がブログとかで書いていてくれそうなところ(ディリクレ過程とか、中華料理店フランチャイズとか)はまるっと飛ばして、実装に必要な定式化＆導出にしぼってまとめていくつもり。*1 とりあえず syou6162 さんや nokuno さんのこの辺の記事とかご参考

これは微妙に昨日の話だが、GPGPU 実習のミーティング。あまり時間はないのだが、手を動かし始めたら意外に簡単にできるものなので、今週は(お盆休みもあるし)簡単に方向性を決める。 ここから今日の話だが、CUDA SDK のインストール。自分でインストールすればすぐ終わると思うのだが、自分がいつまでもやっていてもよくないし、インストールしてもらうのもありかと思い、隣でインストールするのを見る。そういえば、自分も Unix の使い方を覚えたのは、ずっと相談員席に坐って隣の先輩方(場合によっては後輩であることも)がばしばし使うのを見ていたからであって、こういうのって物理的に隣にいて使い方を見ることができるのが大きいのかもしれない。 ブートキャンプの名札を返しに行く道すがら、aki-su さんとすれ違う。博士論文の最終審査はどうでしたか、みたいな話をする。よく思うのだが、博士後期課程というのはあり

Finkel+2005, Incorporating non-local information into Information Extraction Systems by Gibbs sampling 最大エントロピーモデル ・素性値の経験分布での期待値とモデルによる期待値が一致するという制約 ・制約から対数線形モデルを導出 ・尤度関数の線形重みに対する勾配は閉じた式で書ける 正則化項を加える場合も、普通は微分可能なものを選ぶ（L1正則化なんか微分できない部分があるので一工夫が必要） ・勾配には、モデルによる素性値の期待値が含まれる モデルが複雑な場合（例:CRF）、期待値の計算の効率化が必要（DPなど）←ポイント！ 最大エントロピーモデルのパラメータ推定 ・尤度（＋正則化項）の最大化 ・勾配を使った近似解法 上記の勾配を使って、尤度を大きくするような方向に重みを調整していく ← 期待

あくまで調べ中。なんだけど自分用にメモしておく。 大雑把に言うと、LDAは α=>[θ=>[z=>w]]<=β α,β: パラメータ θ,z : 潜在変数 w : 観測データという形をしていて、観測データの尤度を計算するには潜在変数θおよびzについて周辺化しないといけない。ところが潜在変数間に依存関係(θ=>z)があるので、θ、zそれぞれ独立に周辺化できない。 そこでBlei論文では変分ベイズ法という方法を使ってθとzの依存関係を切り離す方法をとっている。一方でGriffithsらのギプスサンプラを使う方法ではサンプリングしたzを使うことでzを観測データにしてしまうことで上記問題を解決している(多分 ついでにβにもディリクレ事前分布を導入していてBlei論文でのβをφ、ディリクレパラメータをβとしている。紛らわしい。その結果 α=>[θ=>[z=>w]]<=[φ]<=β α,β: パラメー

一応CSAの記事を書き終えたので、各記事へのリンクリストを。 補足:記事を7つも読むの面倒くさい人は、↓にもう少し簡単な圧縮法の解説を書いておいたので参照されたい。 15分でわかる(とうれしい)Suffix Arrayの簡単な圧縮法 Compressed Suffix Arrayの解説(1) -Suffix Array- Compressed Suffix Arrayの解説(2) -SAの計算量- Compressed Suffix Arrayの解説(3) -圧縮の方針- Compressed Suffix Arrayの解説(4) -unary記法- Compressed Suffix Arrayの解説(5) -Succinct Bit Vector- Compressed Suffix Arrayの解説(6) -B Vectorと Ψ Vector- Compressed Suffix

大規模データを日常的に扱う人にとって、データ圧縮は基本。絶対ないと困るわけではないけど、あると格段に世界が広がる。ドラクエで言うところのルカニみたいなもの。 でも圧縮というとデータをバイナリで持たないといけないとか、なんとなく面倒なので目を背けがち。そこで5分でわかるような感じで説明を書いておく。 基本的な圧縮の方法は差分圧縮というのがある。今回はこれを説明する。 char型のデータが8つ並んでいると考える。 6 3 2 1 7 5 4 8とりあえずバイナリにしてみる。便宜上、縦に書く。 6 3 2 1 7 5 4 8 =============== 1の位:0 1 0 1 1 1 0 0 2の位:1 1 1 0 1 0 0 0 4の位:1 0 0 0 1 1 1 0 8の位:0 0 0 0 0 0 0 1 16の位:0 0 0 0 0 0 0 0 32の位:0 0 0 0 0 0 0 0

100 万行のテキストファイル（test-data）を C/C++ で作成したプログラムで読み込むとき，どのくらいの時間がかかるかを調べた結果です． データ入力がボトルネックになるような状況では，std::fgets(), std::fread(), std::istream::read() を使った方が良さそうです．std::istream については特に極端な差が出ていますので，速度面を重視する場合，便利なインタフェースを封印しないとダメっぽいです．実に惜しい…． 追記（2010-07-28）：id:metaboles さんより，std::ios::sync_with_stdio(false) を使えば std::cin.getline() や std::getline() も std::fgets() と同じくらい速くなるというコメントをいただきました（後述）． $ wc test-