カテゴリ[r] - ChangeLog

* 単語アライメントと機械翻訳 [r]

対訳単語アライメントが、今の品詞タグ付けツールぐらいの完成度（汎用
性）で公開できるといろいな可能性があって、面白いとは思うのよね。い
ろいろな可能性の一つに、機械翻訳への貢献があるかもしれないけど、そ
れだけに限らないと思う。むしろ、機械翻訳以外の分野と絡めると面白い
と思う。

単語アライメントは機械翻訳と違う。

* タグ付け [r]

とりあえず、200 文。1/10 完成。疲れた。
タグ付けの当面の目標は、250 文ぐらいにしよう。

* BioNLP [r]

ごぶさたなネタですが、UPenn がとうとう PubMed の Treebank を作った
らしい。

http://bioie.ldc.upenn.edu/publications/latest_release/

viva 力業 ! すげー。

仕様をさらっと読んだだけだけど、私が訴えつづけた
tokenization ambiguity の問題意識
は共有できているみたい。よかった。

Some of our tokens contain white space, when it is included between parentheses inside a single chemical word;
some are substrings of what would be considered a token in Penn Treebank.

annotation tool は Tom Morton が作ったみたい。以前、何度かデモを見
せてもらったことがある。ツールとしては、とても高い完成度で、職人気
質を感じました。

一方、辻井研も頑張っています。Treebank のベータ版もできている。

http://www-tsujii.is.s.u-tokyo.ac.jp/GENIA/

ちなみに、依存構造のアノテーションもあるみたい。

http://www.ifi.unizh.ch/cl/kalju/download/depgenia/

データが揃ってきたから、昔の named entity recognition rush のよう
に、今度は、構文解析バブルがおきるんだろうね。Charniak parser も
2,3 年前から、PubMed 用のモデルがあったから、そのうち、チューニン
グされたパーザーがでてくるんでしょう。

放置しておけば、２年もしないうちに、有志の皆さんがやってくれるでしょう。

* 結果を眺めながら、タグ付けしながら、妄想 [r]

いいかげんに作った対訳モデル(確率つき対訳辞書)を Darts で検索可能
な辞書にして(この辺りもう少し賢くできそうですが、今回はくどうくん
の恩恵をうけてお手軽に)、Viterbi/MWM/RMM でアライメントさせた結果
を、まじめに、眺める。

ビタビアライメントでも、二部グラフマッチでも、安直なデコードでは、
残された課題を本質的に解決することができないことに、いまさら、気づく。

どうしたものかねぇー。まぁ、攻め方はいろいろあると思うから、思いつ
くものから試してみるか。いささかあきらめモードなんだけど、制限時間
ぎりぎりまで、頑張ってみよう。

タグ付けも同時進行。今日でやっと 150 文。先は長い。
やっぱり、500 文は準備しないと。＞ 小人さん（ぇ

* グラフマッチング [r]

「最適」割り当て問題を考える上で、「最適」の定義が結構むずい。

「最大重みマッチング」は、エッジ重みの総和を最大にすることを考えた
アルゴリズム。で、有名なやりかたは、あの、ハンガリー。

それに対して、rank-maximal matching といって、greedy にマッチング
していく方法もあるらしい。G = (V, E) で V が A と B に分割されてい
るとする。割り当て問題だとすると、A が人の集合で、B が仕事の集合。
で、このとき、A のそれぞれの要素 a は、自分ができる仕事の優先度付
きリスト [b1, b2, ... ] をもっている。で、ある優先度 1 以上のエッ
ジを対象にしてマッチングする、次に優先度 2 以上のエッジを対象、3、
とどんどん続けて r までマッチングをする。

このやり方も http://www.mpi-sb.mpg.de/~michail/rmm.shtml によると
ハンガリーでできるらしい。（間違っているかも。なんせ、論文の内容は
ほとんどわかってない。）

ポイントは、エッジの重みで何を表現しようとしているか、につきるかと
思う。人間 a と仕事 b のすべての組み合わせの total order がわかっ
ていれば、教科書通りの maximm weighted maximum cardinality
matching で最適な解が求まるはず。（たぶん。自信なし。）ただし、片
方の優先順位しかわかっていない（仕事 b の優先順位がわかっていない
とき）は、エッジの重みでは表現しずらい。そんなときに役立つらしい。

で、単語アライメントの場合は、どうなんだ？ partial order しかわか
らないけど、でも、一応、日英の両方の組み合わせがわかっているから、
エッジの重みはきちんと定義できそう。だから rank-maximal ranking に
しなくてもいいのかな。

ただ、現実は、両方向で conditional prob (P(e|f) と P(f|e))を求めて、
苦しい紛れの補完係数つけて joint prob として扱って total order に
するぐらいなら、partial order でランク付けした方が吉かなぁ。

わからん。 わからん。 わからん。 わからん。

うーん。どうしよう。うぅぅ。

* Data-Driven Machine Translation [r]

機械翻訳の研究は、「統計」と絡めないと認められない時代に入ったでしょ
うか。2001, 2003 年に開催されたワークショップは、今年も開催される
みたいです。ただし、今回は、data-driven ではなく、statistical であ
ることが重要なようです。

http://www.statmt.org/wpt05/

ちなみに親サイト http://www.statmt.org/ は Philipp Koehn が運営し
ているみたい。

今回のワークショップは、「統計」しない機械翻訳は、排除している感じ
です。あと、アイヌ語とか希少言語を対象にしようということみたいです。
日本語を片言語にすると、もう片方の言語の選択は resource-poor でな
いとまずい。英語はもちろんのこと、フランス語、ドイツ語、中国語、韓
国語は resource-rich なのでだめ。東南アジア系の言語ならOKかも。 こ
れも、時代の流れなのでしょうか。

ちなみに、今回も shared task があるみたいです。評価型ワークショッ
プにして、ソーシャルネットワーキングして、研究者仲間を集めて、数字
で勝負して、brain storming を行ない、最後はお互いを励ましあう。こ
れも時代の流れなのでしょうか。

前回の shared task の発表は、わざと面白い視点を捨てるように、規格
化を推進しているようで、なんとなくしっくりこなかった。救われたのは、
Ted Pedersen がとってもいい人で、率先して、多様性を認めるように話
をもっていっていた。今回はどうなるでしょう。

私は、「統計」と絡まないし、resouce-rich な言語対だし、そもそも間
に合わないから、提出しない方針。これからの機械翻訳関連の研究は、い
ままで以上に統計を語らないと、肩身が狭いようですね。多様な視点がま
だ許される時代に、この分野と関われて幸せだった、と思う。

* The Hungarian Method [r]

昨日は勢いで思ったが、assignment も one-to-many や many-to-one は
対象外にしている気がする。もう少し、調べてみよう。

* The Hungarian Method [r]

最適割り当て問題の解説は、↓にもありました(pp.66-70)。
http://www.amazon.co.jp/exec/obidos/ASIN/4535601402/ref=pd_sims_dp__5/249-0022586-9255571

この講義ノートが、私にとって、一番、わかりやすかったです。
http://www.cs.ucsb.edu/~suri/cs230/Matching.pdf

恥ずかしい話だが、bipartite weight *matching* と bipartite weight
*assignment* は同じものだと思っていた。

A matching in a graph G=(V,E) is a subset M of the edges E such that
no two edges in M share a common end node.
An assignment in a bipartite graph is a matching M such that each edge
of the graph has an incident edge in M.

とんだ勘違いだった。one-to-many や many-to-one 型のアライメントを
扱いたかったら、assignment を考えるべきなのね。あ、まだ傷口が小さ
い段階で、気がついて、良かった、良かった。
＃ 後記: matching も assignment も one-to-one の対応でした。
＃ 勘違いの勘違い…。

* 久しぶりのマッサージ [r]

疲れが溜っていたから。３０分。極楽。家路への帰り、スターバックスへ
いく。チャイラテを飲む。

思わぬ展開になって、なぜか「紅茶のおいしい入れ方」のについて講釈を
聞く。学んだことは（誤解も含めて）、

- 形容詞にも連用形は存在する。
  しかし、助動詞で呼応させるのが通常の用法。
  e.g. 「おいしかった」「おいしくない」

- 形容詞の連用形の後に、動詞を続ける用法は、不可らしい。
  e.g. 「紅茶をおいしく入れる」は * マークらしい。
  正しくは、「おいしい紅茶を入れる」だろう、ということ。

- こういうヘンテコな現象をコリージョン(その人の発音から、
  back-transliteration できなかった)というらしい。
  ＃ 後記 コアジョン？かなぁ。でもスペルわからない。

勉強になりました。もちろん、美味しいチャイでした。

家にかえって、気になったから、Cabocha で解析させてみた。

* 0 1D 0/1 0.21236038
紅茶 コウチャ 紅茶 名詞-一般 O
の ノ の 助詞-連体化 O
* 1 2D 0/0 2.00199354
おいしい オイシイ おいしい 形容詞-自立 形容詞・イ段 基本形 O
* 2 3D 1/2 0.00000000
入れ イレ 入れる 動詞-自立 一段 連用形 O
方 カタ 方 名詞-接尾-特殊 O
を ヲ を 助詞-格助詞-一般 O
* 3 -1O 0/0 0.00000000
習う ナラウ 習う 動詞-自立 五段・ワ行促音便 基本形 O
。 。 。 記号-句点 O
EOS

どうも、「紅茶」が「おいしい」に係ることが不自然、ということを説明
したかったようだ。。

* 業務連絡 (続 The Hungarian Method) [r]

内山さんから、任意の無効グラフの最大重みマッチングを求めるプログラ
ムのラッパー(mwm)を提供してもらいました。早速、使ってみました。

例えば、この対訳文だと

夜 が 明けよう と する 頃 やっと 仕事 が 終わった 。
I finally finished the job just as the dawn was about to break .

ベースライン(いわゆる P(e|f) と P(f|e) のリンク集合積をとる方法で
precision はとても良い、recall はあきらめた方法)はこんな感じでした。

6 やっと 1 finally
9 終わった 2 finished
7 仕事 4 job
5 頃 10 about
10 。 13 .

今回の、最大重みマッチングによる方法。最初のコスト行列は、P() を
log() とって、 -1 かけて、逆数にする、ふつーのやりかた。あ、一応、
e->j と j->e 方向それぞれにコストだして、「苦しまぎれのα」で線形
補完。

0 夜 5 just
1 が 0 I
2 明けよう 3 the
3 と 6 as
4 する 11 to
5 頃 10 about
6 やっと 1 finally
7 仕事 4 job
8 が 9 was
9 終わった 2 finished
10 。 13 .

まだ、評価する段階じゃないけど、recall は 0.302470119521912 から
0.353147410358566 に上がりましたが、precision は下がっていそう。
＃ I-world データは、部分的にしかマークされていないから、
＃ recall しか計算できないのが、難点。
＃ これの完全正解データを作るべきなんだろうなぁ。(泣)

先週は、The Hungarian Method で止まっていて、敗北だったが、試せる
ようになったから、少し進歩。

ありがとうございます。＞ 内山さん
まだ感触がつかんだばかりで、工夫の余地はありそうなので、いろいろ試
してみたいと思います。まとまったら、ご報告します。

* The Hungarian Method [r]

かなり回り道をしていたが、要は、この問題を解けば、対称コストでやる
方法を再現できるらしい。しっかし、肝心のアルゴリズムがわからんのだ。

http://www.cs.elte.hu/egres/design/generated/pub_techrep55.html

やっと、それっぽいライブラリが見つかったけど、今は商用ライセンスが
必要らしい。↓。日本ではただの評価版が見つかる。↑。ダウンロードし
たら、今度は、tar で展開できない。↓。ゆえに、本日も、敗北。

* GB [r]

Dyama さんが、MED のかじりを紹介してくれる。情報幾何的な解釈
projection もさわりだけ。受信側が勉強不足だから、なんとなく、面白
そう、ってとこまでしか、共有できなかったけど。孝ちゃんが、Boosting
as Entropy Projection を読んでいるとき、「目的は現在の仮説分布と似
たような分布を選びたい。でも、間違ったものへの重みをアップするよう
に制約をかけたい。」といってくれて、すっきり。

高村さんは ICA再訪。自分では絶対に追えない内容だけど、ご自分のこと
ばで解説してくださるから、わかりやすい。今回紹介してくれた方法は、
従来と違って事前分布を取り込める方がスマートらしい。そもそもICA は、
難しすぎる問題を解こうとしている感がある。最後のパラメータチューニ
ングは、heuristics というか問題ドメインの鋭い洞察がないと、なかな
か精度がでそうにないですね。

孝ちゃんは、Boosting とあれネタについて、いろいろ。Dyama さんが、
オブジェクト指向プログラミングの極意を伝授してくれる。ふむふむ。ま
だ私は汎用クラス消費者レベルだなぁ。生産者レベルまでスキルアップし
たいものだ。

奥村研輪講。

最後が私。とりあえず、I-world とデータ前処理の説明。説明がヘタレだ
から、誤解を招いてしまった。えっと、簡単にいうと、unsupervised に
モデル学習（ざっくりいうと、確率つき対訳辞書を構築）して、そいつと
未定のアルゴリズムをつかって、decode することを考えている。力点は
decode 手法、I-world のデータは評価データとしてしか利用しない、と
いう方針を明確に表明しなかったのが、敗因。まだ、何を評価すべきか、
分かっていないから、しごくマトモな指摘にも、意味不明な返ししかでき
ない。××

皆さんお疲れなのに、あーでもない、こーでもないといろいろ知恵を下さ
る。最後に、これは、まさに、あれで解けますよ、って高村さんの頭には
ひらめきがあったようだ。が、私は鈍いので、キャッチできない。Dyama
さんが少し解説を加えてくれた。わかった気分にだけなった。意図を理解
するのに、もう少し、時間が必要。勉強しないと。

夜、KMも一緒に、町田で打ち上げ。３ヶ月ぶりぐらいで、飲み会等々に参
加。疲れがピークだったからか、何をしゃべったか覚えていない。

* Welcome to the I-world [r]

英語もなんとも厄介。終わらない…。日本語同様、かなり、てこずる。
せめて、ベースラインの実験を報告したいと思っていたが…。
もう、無理。

* Welcome to the I-world [r]

日本語側の読みときパーザを仕上げる。
だけど、ルールをたくさん書いても、とりこぼしが残る。
手で修正しちゃった。目先の快楽を求めてしまった。
もうちょい頑張ると、partially labelled word alignment corpus ができそう。
でも、この調子だと、間に合わない。前回同様、やばいですねぇ。
とにかく、枝葉末節なことはほっといて、がんばろぉー。

あ、やばい。翻訳学校の宿題がまだ残ってた。寝ようと思ったのに。むむむぅ。

* Welcome to the I-world [r]

広義の辞書と解析器がほしい。
辞書は、I-to-J 辞書と J 言語で書かれた I-pedia かな？
解析器は、I-parser と I-to-J translator。I-paraphraser ではダメ。

時間かけて何度読み返しても、わからへん。
５月、９月、と失敗して、３度目の正直で気合いを入れて挑んだが、激沈。

ALT-JAWS があると謎解きに役立つかもしれないけど、気安めにしかなら
んだろう。根の部分がさっぱりつかめない。頭悪すぎ＞私

あー、めげそう。というか、もう、投げ出したい。許されないけど。

* ごめんなさい [r]

年次大会の原稿について、ごめんなさい。

- しめきりを守れませんでした。８日午後に提出しました。

- 開かない pdf を送ってしまいました。
  その後、鳥澤先生からメールがあったのですが、タイミング悪くて、お
  返事が遅れてしまいました。ごめんなさい。

- ３週間前に提出したアブストラクトと実際の原稿の内容がかなり異なり
  ます。「fail to でっちあげ」(copyright Dyama) になりました。

- 謝辞書くのを忘れました。

本研究は、工藤拓氏の実装を参考にしました。貴重な助言もいただきました。感謝いたします。
言語資源を開発された方々にも、感謝の意を申し上げます。
山田寛康氏、高村大也氏、乾孝司氏、坪井祐太氏から、有意義なコメントをいただきました。各氏に感謝申し上げます。

- ポスター用の ppt を準備していたら、致命的なミスが見つかりました。

誤植その１：P(y|x) 式の exp に、括弧をつけ忘れました。

誤植その２：P(y|x) 式の添字が間違っていました。

誤植その３：対訳素性 singleton の属性の順番と実際に学習された対訳
素性の属性の順番が対応していませんでした。わかりにくさを増やしてし
まって申し訳ないです。ちなみに、学習された素性の重みは正しいです。

- 誤解を招く記述がいくつかありました。特に、「基本辞書」と「基本シ
ナリオ」は、同じ用語を使ってしまいましたが、関係ありません。「基本
シナリオ」でも、辞書を追加していますが、その追加シナリオが基本だ、
という意味です。

原稿は、今回の小さな思いつきは徒労に終りましたという、負の結果なの
で、読む価値ないんですが、読んでしまった方々へ、お知らせいたします。

そんなに苦労して、ぜんぜん旨味がないじゃん、と言われれば、それまで
のお話です。後で冷静に考えると、今回の話は、うまくいかなくて当然な
のかも。新語形成で重要な音韻論的な視点を反映していないし、そもそも
英語以外の借用語も結構あるし…。

* Welcome to the I-world again [r]

終日格闘。ちと、解読成功。残された課題多し。

* Welcome to the I-world [r]

気合いをいれて、再度挑戦。今日は、進歩がなかった。

* 文字列の長さゼロの見出し語に注意 [r]

活用して、語幹の長さがゼロになるエントリがあった。「る」。

,0,接尾辞,動詞性接尾辞,母音動詞,基本連用形,る
,0,接尾辞,動詞性接尾辞,母音動詞,未然形,る

いままで、くどうくんが処理してくれてた辞書を利用していたが、今回、
辞書拡張に伴い、活用を自前でやったら、こんなエントリを生成していた。

で、はまった。もう、投げ出したくなったが、助けてもらって、解決。
なんとか、週末学習させることができた。感謝。

* Re： MeCab 0.90 業務連絡 [r]

情報ありがとうございました。そうです。あの実験結果です。こちらは、
コーパス(Kyoto Corpus 3)も辞書(juman dic 4.0)で、バージョンが激し
くことなります。ついでに、素性テンプレートやハイパーパラメータも微
妙に違います。なので、単純には比較できないんです。はい。

手元の実験では、Gaussian regularizer で、ハイパーパラメータを 1.1
に設定しました。私の実装だと、辞書だけで F値が 92 ぐらい。コーパス
の出現したトークン込で 95 ぐらい。ただ、評価は、活用型・活用形まで
みた品詞情報の完全一致です。(all に相当。)

ずぼらだから、有意さの検定はしていないのですが、ちょっと、単純に数
字が悪すぎるかな、と思って、コーパス中のトークンを学習時に投入して
みたわけです。

日本語の場合、形態素解析器には外部辞書が付属されていて、これは学習
したコーパスと別々に作っていることが多いです。（コーパス中のタグと
整合していないこともあります。）でも、英語の場合、辞書がなく、タグ
付きコーパスからしか学習しないから、mkdic の際に学習用のコーパスか
ら得られたトークンを解析器内部の辞書エントリとしても、問題ないよう
な気がします…。

どうなんだろう。

* コーパスを無視した学習だった。 [r]

くどうくんのコードをみつつ、自分でコメント付けながら実装し直して、
あのバグがやっととれたというのに、論文で報告されているような数字が
でていなかった。…

原因がやっとわかった。mkdic でコーパスを指定していなかったから、辞
書が juman の配布されたものだけになっていた。なんか、やたらと
virtual token が追加されてて、こいつら、辞書にないから未知語処理に
まわされちゃうよなぁー、とか思ってはいたが、なぜ、もう一歩先が読め
なかったんだ。しょっくぅ。

* カタカナ [r]

カタカナ文字列をみて、その品詞は？ とひたすら自問した一日。

普通名詞かサ変名詞かで、結構、悩む。
「イベント」- event
「コントロール」- control
「デモ」- demo
「イメージ」-image

「コメント」だと、を抜きにして、サ変名詞といえるかも。
「ノーコメント」だと、どうも、普通名詞っぽい。

ちなみに、京大コーパスでは、カタカナ文字列は、外来語としてサ変名詞
とする傾向にあることを、今日知った。「ネタ帳」の「ネタ」はサ変名詞
だった。

* 午後だけ参加 [r]

そろそろ、外部刺激に堪えられるようにならないとまずい。リハビリのた
め、参加者が極端に少ないであろうと予想された、２日目の午後だけ、聞
きにいく。

興味があったのは、最後のお話。いままで、論文だけしか読めなくて、発
表を聞くチャンスがなかったから。やはり聞いてみると、思想とか苦労の
軌跡が詳しくわかって良かった。通訳・翻訳学校の講師の方々には、国際
放送のニュースライターもいらっしゃって、翻訳支援システムの利用者と
開発者の両方の話がわかった。ここが、ひとりで、楽しんでいたところ。

ご本人には、後で雑談させてもらった時にいったんだけど、グループ化と
並べ替えの処理の順番を逆にしたらいいと思う。グループ化された系列に
対する対応付けという問題設定だが、そもそもグループ化せずに、それぞ
れの NE 単位で、IBMモデル3をつかって、(ただ、クラスモデルにしたけ
れば、モデル4にしてもいいけど、)グループ化は、照応や参照同定
(record linkage)の問題で使われているクラスタリングを参考にして、別
途に、考えた方がいいんじゃないかと。ご本人がおっしゃっておられたが、
グループ化が、とくに content-aligned の場合、重要だ、という意見に
賛成。NHKニュース原稿の場合は、特に、相手言語をみて、照応の解消が
できる場合もあるらしい。提示方法も、グループ化無しでは考えられない
というのも納得。ただ、現手法の文字列の部分マッチでは、もったいない。
本格的に、食いついてみたら良さそうじゃないかな、という気がした。

* 今日も make た [r]

今年も ACL は見送り。玉砕されても立ち直る根性がないので。
主流な会議はすべて、挑戦する前に、あっさり、負けておく。

それより、言語処理学会だよ。年度末の成果報告会だよ。問題なのは。年
明け、おくむら先生に、アリバイ創作作業に協力要請して、なんとか乗り
切りたい。

それより、さらに問題なのは、４／１５だよ。気づくと、人生の第？章の
デットラインは、あと、４か月後に迫っている。「あせらず・あわてず・
あきらめず」だ。

* 今月になって一番 make とタイプ日かも [r]

デバッグ作業のつもりなんだが、エンバグ作業になっていた懸念あり。
不毛な作業を減らす努力をしなければ。もう、間に合わない。だめだぁ。

* Non-Emperical methods in NLP [r]

ちょっと Kevin Knightの論文が読み
たくなってページをみていたら、こんな SIG があるらしい。

http://www.isi.edu/natural-language/people/nemnlp06.txt

NLPの業界で、何をもって emperical methods と主張できるのか不明なん
だが、この方法は emperical じゃないって主張する方がもっと難しそう。

* AER [r]

AER (Alignment Error Rate) は、わかち書きが正しいという前提の評価
尺度である。わかち書きが間違っている可能性がある時はどうしたらいい
んだ？ cAER (character-based Alignment Error Rate) ？ mAER ？！

データみていて気がついたんだが、juman の ContentW.dic にとって、
「補佐官」は未知らしい。「長官」は既知だけど。「補佐」は、サ変名詞
となっていて、cost(普通名詞-普通名詞) < cost(サ変名詞-名詞) だから、
選ばれなかったのね。

コンドリーザ コンドリーザ コンドリーザ 未定義語 15 カタカナ 2 * 0 * 0
・ ・ ・ 特殊 1 記号 5 * 0 * 0
ライス らいす ライス 名詞 6 普通名詞 1 * 0 * 0
国家 こっか 国家 名詞 6 普通名詞 1 * 0 * 0
安全 あんぜん 安全だ 形容詞 3 * 0 ナ形容詞 21 語幹 1
保障 ほしょう 保障 名詞 6 サ変名詞 2 * 0 * 0
担当 たんとう 担当 名詞 6 サ変名詞 2 * 0 * 0
大統領 だいとうりょう 大統領 名詞 6 普通名詞 1 * 0 * 0
補 ほ 補 名詞 6 普通名詞 1 * 0 * 0
佐官 さかん 佐官 名詞 6 普通名詞 1 * 0 * 0
を を を 助詞 9 格助詞 1 * 0 * 0
指名 しめい 指名 名詞 6 サ変名詞 2 * 0 * 0
する する する 動詞 2 * 0 サ変動詞 16 基本形 2
。 。 。 特殊 1 句点 1 * 0 * 0
EOS

対応で考えると、語源は、<advise,補佐> だろうから、そこからなんとか
救われる方法が見つかるといいんだが。どうしたものか。

* 良い対訳文とは？ [r]

翻訳者のタマゴとしては、原文がすけてみえる対訳文を嫌う。MT関連研究
者のタマゴとしては、対応関係がわかりやすい対訳文なくしては、話がは
じまらない気がする。

どんな立場でも、正確に原文の意図をくみとって、別言語で忠実に再生成
するという大原則はかわらんのだが、なんか、対訳文の位置付けが矛盾し
ている。もやもやと葛藤があって、整理つかない。

* SMT のいまさら [r]

SMT で、word alignment を対訳コーパスから学習する vanilla モデル
(IBM方式)は、原言語の１単語は、たかだか目的言語の１単語に対応する
という仮定でモデル化している。こうすると、複数語で対応するときが問
題だ、という自明な批判がはいって、かわすためにいろいろ拡張がある。

その一つに、alignment template なる方法 (Och ら 1999) があるのだが、
その中で、初期の alignment matrix を作るのに symmetrization という
操作を行なっている。なんのこっちゃない、f->e と e->f の両方を学習
させて Viterbi alignment を算出して、alignment links の集合積と集
合和をとっているだけ。(正確には、集合積リンクから少しずつ拡張する
ため提案もしているけど。)

実は、この集合積の precision がかなりいい。論文では、Verbmobil (英-独)
で88.4 とあった。長い文でも precision がいいかな、と、気になったので、
やってみた。

内山コーパスの上位 500 文で学習、新聞リード文の対訳でテスト
内山コーパスの上位 5000 文で学習、新聞リード文の対訳でテスト
内山コーパスの上位 50000 文で学習、英字新聞リード文の対訳でテスト

内山コーパスは、読売新聞で同じ分野。にしても、見た目、すごくいい。
悔しいから、特許でもテストしてみた。

内山コーパスの上位 500 文で学習、特許の背景文の対訳でテスト
内山コーパスの上位 5000 文で学習、特許の背景文の対訳でテスト
内山コーパスの上位 50000 文で学習、特許の背景文の対訳でテスト

こっちは、そこそこ。分野が違うと、recall がはげしく落ちるのが観察
されるぐらい。

…手ごわい相手だ。フリダシに戻ってしまったかも。やばいぞ。＞ 私

* ブログで知識獲得 [r]

今日、宿題をやっていたのに、それを忘れて読んでしまった。
http://blog.livedoor.jp/y-46/

本来の目的は figurative speech というか as adj as .. のイディオム探し。
http://efl.htmlplanet.com/similes.htm

この ChangeLog はただのワタシノキロクだから、他人に役立つことを書
くつもりはないけど（というより書けない）、ブログで学ぶことって案外
多い、としみじみ感じた。

＃ 他のO研究室のメンバの、「いまさら…」という声が聞こえそう。

* GIZA++ のいまさら [r]

どのオプションが指定できるかわからなかったので、親切な人が、web 上
で説明してくれているかも、と甘い期待をもって、ぐぐる。敗北。

しかたないので、コードをちまちま読んで、ディフォルト値を書き出して
みた。何も指定せずに、GIZA++ を実行すると、簡単なオプションの説明
が出力されるけど、実際は、はるかに複雑なことが指定できるようだ。
EM学習したあと、*.gizacfg で出力されるのが、実際に使用したオプショ
ンとその値のログ。

学習したモデルで、テスト対訳文に対して、Viterbi alignment をもとめ
たかったら、TC オプションで指定すれば良かったのね。

% ./GIZA++ \
  -S crl50k+japiobk_vcb.en \
  -T crl50k+japiobk_vcb.ja \
  -C crl50k_snt.ej \
  -TC japiobk_snt.ej \

関連論文にも、簡単に Viterbi alignment を求めたって書いてあるけど、
どうやったんだろうとか思っていたら、こういうオチやったのね。あぁ、
知らなかった。コードみると、reference translation と比較できそうな
関数もあるから、ひょっとしたら AER (Alignment Error Rate) もよろし
く算出してくれるのか？！謎、深まる。

＃ こんなの、 SMT をやっている人には、常識だろうな…。

辞書と共起頻度ファイルをうまく組み込む方法は、一応、README に書い
てあるが( C. Dictionary File のセクション と Part VII: New
features の -DBINARY_SEARCH_FOR_TTABLE と -CoocurrenceFile FILE の
説明) どうなっているのか、今だ不明。気が向いたら、調べてみよう。

* 補足 [r]

新しい Och さんの ページ http://www.fjoch.com/
今後の G 社の翻訳機能に期待しよう。

* 論文のコピーをお持ちでしたら、御連絡ください。 [r]

ダブル配列で有名な青江研究室のお仕事だから、

トライ構造を用いた多言語対訳辞書の効率的圧縮手法
○住友　徹、森田和宏、泓田正雄、青江順一（徳島大）
情報処理学会第６１回全国大会，2T-4，pp.2-133〜2-134 (2000年10月).
http://www-b3.is.tokushima-u.ac.jp/research/koen.html

ぜひ読んで見たいが、アクセスできない。東工大の図書館、いけへんし。

メモリ増えようが、プロセッサが速くなろうか、時代に関係ない。
いつでも、美しい辞書検索アルゴリズムに憧れます。

* ニワトリとタマゴ [r]

わかち書き、品詞付与、マイニングした品詞対応の上位だけを信じて、残
りを対訳辞書検索。対訳辞書検索から対応文字列区間を確定、残りをわか
ち書きと品詞対応で埋める。ぐるぐる。

ニワトリもタマゴも、両方、着実に成長してくれると嬉しいのに。

品詞タグ付けも対訳辞書検索も、所詮、辞書をトライで格納して共通接頭
辞検索しているし、もうちょっと美しくできないものかねぇー。

* 言語処理学会 [r]

アリバイ？工作しないと、さすがにまずい。しょうもないことでも捻出で
きない、今日この頃。まいったなぁ。

* 単文なのに、お手上げ [r]

一応、プロジェクトでは、複文・重文を扱うってことになっている。
しかも、表向きは、生成をするってことになっている。

しかし、基礎日本語文法（改定版、オレンジ色）の単文の章でつまづく…。
手ごわい、テンスとアスペクト。もう、メゲそう。

* 品詞対応サンプリング [r]

恣意的に選んでみた。<VBN, 動詞:未然形>。理由は、全体で 657 文しか
ないし、私の内省とも一致するペアということで。でも結果は、イマイチ。

http://www.lr.pi.titech.ac.jp/~kaoru/dictlook/1349_pxj.html

緑色が、文字列の品詞が VBN か、動詞:未然形になったもの、黄色が動詞っ
ぽいやつ。（動詞性接尾とかを含む。）一応、複文を集めたものらしいの
で、述部は２つ以上あるだろうから。

まだ、エラー分析していないからなんとも言えないけど、微妙な感じ。

他の品詞との絡みもみないといけないけど、3101, 3116, 3122 なんか見
ると、「サ変名詞＋れる」が英語の動詞一語に対応する場合、うまくいっ
ていないな。他にも激しく間違っている文もあるし。むむむ。

直接的な品詞対応がアライメント精度を向上させるという主張もみかける
が、実際どうなんだろう。

* 品詞対応を無理矢理マイニングしてみた [r]

内省に基づく解析が無理だったので、単純に、コーパスからの統計に頼る。
条件は、連続的でかつ最長３つまで。一応、連接表の前件と後件を意識し
たつもり。

品詞体系は、２つの組み合わせ <PTB, 益岡・田窪文法＋α> と <PTB,
ipadic> が可能なので両方してみる。ただし、10000文だけを対象にする。

類似度は共起頻度で重みを付けたダイス係数…。左から、、英語の品詞列、
日本語の品詞列、共起頻度。ここんとこお気に入りな動詞周りの活用だけ、
上位１０件、抜き出してみる。

<PTB,益岡・田窪文法＋α>の場合：

VBD 動詞:タ形 3229
VB 動詞:基本形 1940
VBZ 副助詞:* 普通名詞:* 1055
PRP VBD 動詞性接尾辞:タ形 535
VBP 動詞性接尾辞:基本形 655
TO VB 形式名詞:* 526
VBN 動詞:未然形 657
VBG 格助詞:* 動詞:タ系連用テ形 415 1524 1263
PRP VBP 格助詞:* 動詞:基本形 237
PRP VBZ 形容詞:基本形 句点:*

<PTB,ipadic> の場合：

VBD 動詞-自立:連用形 3045
VB 名詞-サ変接続:* 1956
PRP VBD 名詞-代名詞-一般:* 1398
VBZ 動詞-自立:基本形 1472
TO VB 名詞-非自立-一般:* 662
VBG 動詞-自立:連用タ接続 助詞-接続助詞:* 526
VBN 動詞-自立:連用形 助動詞:基本形 448
VBP 名詞-形容動詞語幹:* 441
NN VBD 助詞-係助詞:* 名詞-一般:* 助詞-格助詞-一般:* 292
PRP VBP 助詞-格助詞-一般:* 動詞-自立:基本形 221

動詞は、自立と非自立に捕らわれずに、数えあげるべきだった？！

両言語の品詞体系マニュアルをひたすら読みつつ信用ならない私の内省に
頼るよりは、幾分ましだと思う。けどね。 うーん。これで、辞書検索の
候補が絞れるんだろうか。甚だ疑問。

* 動作を表す動詞と状態を表す動詞 [r]

今日は、土曜日なので、午後から、翻訳学校へ。今日の収穫は、「動作を
表す動詞」と「状態を表す動詞」の違いをしっかり認識していなかったこ
と。実は、英語にも、両方を表す動詞が存在していた。例えば、sit。

He sat down and crossed his legs.
彼は座って、足を組んだ。

ここでの sit は、すわらない状態からすわる状態に変化していて、「動
作」を表している。

He sat with his legs crossed.
彼は、足を組んで座っていた。

ここでの sit は、既に座っていた「状態」を表している。

＃ 私は、この sit を「動作」を表しているものと理解して、混乱した。
＃ どうやって、足を組む動作をしながら座る動作ができるのか、と。
＃ かなり致命的な勘違いをしていた。

で、ここで浮上した疑問が、「現在形で、状態を表す動詞」と「現在進行
形で、動作を表している動詞」との違い。講師の人に突っ込んで聞いたつ
もりだが、はっきりした回答は得られなかった。

帰宅中の電車で考えるに、どうも、単文の英日方向の訳出の上では、現在
の時制ならどちらも「テイル」と訳すしかないようだが、ニュアンスとし
ては、前者は、習慣的なもので、後者は、その時制での実際の動作が継続
しているさまをいうようだ。とは言え、まだ、モヤモヤ。

とにかく、日英におけるテンスとアスペクトの対応ってかなり扱いにくい
問題である、ということがだけは、わかった。

* suf [r]

U＠NICT さんから、救援物資が届く。ありがとうございました。

bilingual segmentation でやっているのは、いわゆる word alignment
ではなく、SMT の世界でいう、Viterbi alignment と直接比較するべきも
のではなかった。大きな勘違いをしていた。

私が今やっていることは、ドロヌマから抜けられない状態だけど、考える
ヒントがいろいろあって、ありがたかった。多謝。

* 活用する品詞の対応を考えてみたが、 [r]

私のように、粗雑な頭の人には、無理だと思った。
でも、今は、めげてる時間がない。確実なところから、攻めよう。

* suf [r]

suf --- suffix array による統計量の計算と利用のためのパッケージ
http://www2.nict.go.jp/jt/a132/members/mutiyama/software/suf/suf-1.2/README.ja

http://www2.nict.go.jp/jt/a132/members/mutiyama/software/suf/suf-1.2/ruby/Tutorial.ja
の 2.5. bilingual segmentation (suftrans.rb) が気になって、一式イ
ンストールしてみる。なんか、索引作成のところで失敗してしまった。多
分、共有ライブラリやらのパスを通し損ねたんだと思うが、今日は、原因
を探す根性がなかったので、明日、もう一度、チャレンジしよう。

「対訳候補の句」や「ベストパスの対訳」をどうやって求めているのか気
になる。後者は、SMT の Viterbi alignment と比較して、どうなんだろう。

…って、仕組みを知りたいんだから、コード読めって話か。

* 返信 - 業務連絡 [r]

お久しぶりです。

アドバイスをもとに、
辞書構築の部分を読ませてもらいました。たしかに、makeda を作成して
いる辺りのコードは手ごわいです。darts を作る部分は、自分でもDarts
ライブラリを使っているのでわかるんですが、品詞、活用型、活用形のID
を参照して、ごにょごにょ展開しているところは、今のところ、不透明な
部分として残っています。今は挫折中ですが、今月の下旬ぐらいには、な
んとか、読破したいと思っています。

ありがとうございました。

p.s. あのー、辞書定義をS式でという仕様は廃止できないんでしょうか。
＞ その方面の関係者。

* 動詞の一部だけ活用させてみた [r]

まだ、辞書検索しかしていないけど、活用を展開すると、ちょっとだけ照
合してくれる部分が増えた。両方とも英辞朗を辞書としている場合。
緑色が活用なし、黄色が活用あり。

http://www.lr.pi.titech.ac.jp/~kaoru/dictlook/0/w10000_align_hl_inflect_0.html

今は、活用形候補すべて展開して、日本語と英語の組み合わせすべてで辞
書探索している。超低速スクリプトで実装してる。とても阿呆。

せめて、両言語の品詞間対応と、片言語の品詞連接ぐらいは、見てあげて、
それなりに賢そうな処理してあげないと。実現すんには、もう少し知恵が
いりそう。

* 動詞の活用 [r]

chasen(ipadic) で頑張ってみたが、挫折してしまった。
品詞体系をよく理解していないのが、敗因の理由。
やさしい援護があったのだが、実を結ばなかった。すみませぬ。

方向転換して、juman の辞書でやってみた。こちらの品詞体系の定義の方
が、私にとっては、理解しやすい。実際のわかち書き単位をみると、対訳
辞書の例文を処理するのは、juman の方が向いているかも。大雑把な印象
だけどね。個人的には、英語の活用と日本語の活用の候補をある程度限定
したいという希望があって、例えば、

愛した 愛す 子音動詞サ行 タ形
loved love VBD

とかいう、品詞レベルでの対応がとりやすいかも。chasen だと、

愛し アイシ 愛す 動詞-自立 五段・サ行 連用形
た タ た 助動詞 特殊・タ 基本形

という風に、一般的に短い単位に区切られる。当然、品詞レベル対応がと
れないものもあるから、どちらを使っても、簡単にはいきそうにない。
それぞれ、得意分野があるからだけど、しばらくは、juman 辞書を使おう。

* 評価方法 [r]

機械翻訳風味の研究に仕上げると、機械翻訳ではこれこれという定番評価
方法があるから、なぜその数字を出さない、とかいって、あんまり本質じゃ
ない箇所で突っ込まれそう。設定タスクが標準ではないこと、つまり「風
味」であること、を強調しても、誤解されちゃうことがあるんだよね。

カニカマは、かに風味カマ鉾であって、カニではない。

* juman [r]

4.0 からの「約6万8千語の独自の辞書」を眺めた。かなり、優れモノ。

いまやっているタスクに利用できそうだったので、処理用に加工させても
らった。こういう使い方ってまずいかも、とか思いながら。

* chasen [r]

活用型・活用形は、どこで処理してるんだろう？

* クラスタリング手法のクラスタリング [r]

で、一日が終った。

* チカチカして重い [r]

辞書引き結果をいろいろな形でみる、その４。(１〜３はお蔵入り。)
http://www.lr.pi.titech.ac.jp/~kaoru/dictlook/10/w10000_align_hl_1.html
かなり雑な仕上がり。(色は緑が英辞朗で黄色がEDRで辞書引きした結果)

たつをさんの発表みたいに検索できるようにしていないから、嬉しさ半減。
http://nais.to/~yto/clog/2004-10-29.html#2004-10-29-5

* xassoc [r]

デバッグ作業。やさぐれる（こげる）。
行方向に分割しようとして、すべての行のコード長がたまたま一緒になっ
てしまうと、分割できないじゃん。どうすんだ？！

* xassoc [r]

無限ループに陥る。気持ちが無限ループに入っているから、プログラムに
も伝染しちゃうのかしら。

* ご報告 [r]

進路について、決意を伝えた。快諾いただいた。
この研究室に仲間入りさせてもらって、とても、感謝している。

* スランプ [r]

9 月に入って、頑張らないとまずいのに、ひどい、スランプ。

元気がないから、データ整理。さすがに 12 万文は多過ぎるので、因果関
係に着目した「複文と重文」の例(555 文)を眺める。

あの人は、家が丘の上にあるので、よい景色が眺められる。
The man, whose house is on the hill, can enjoy a nice view.

複数の主題を1文で(無理矢理)表現しようと試みると、構文レベルで言い
換えができる。それらから、構文構造的には優劣がつけにくい。

連体修飾節(埋め込み句)にしたければ、

丘の上に家を持つあの人は、よい景色が眺められる。
The man, whose house is on the hill, can enjoy a nice view.

重文にしたければ、

あの人は、家が丘の上にあって、よい景色が眺められる。
The man lives in a house on the hill and he can enjoy a nice view.

主節と従属節を持つ複文にしてみると

あの人は、家が丘の上にあるので、よい景色が眺められる。
The man can enjoy a nice view as his house is on the hill.

この場合、英文の節の順番の入れ換えが可能。

As the house of the man is on the hill, he can enjoy a nice view.

頑張って 1-1 対応で訳したけど、もし、m-n 対応を許すなら

あの人の家は、丘の家にある。よい景色が眺められる。
The man has a house on the hill. He can enjoy a nice view.

大抵、省略されている文の関係は、読み手にとって都合が良いように、補
完してくれる。だから、ディスコースマーカは、ほとんど、省略可能。
これを発展させると、必然性を伴う表層的な訳し分けルールなんて、
存在しない。

だから、これらの例文から、周辺文脈付きで、「ので」と "as" が対応す
るなんて統計値を出しても、意味がない。これが、３年前の私の失敗。
「A の B」では、A と B の意味的依存関係から「の」に訳し分けがある
のは納得できるけど、品詞は同じ助詞だからって、訳し分け議論は、複数
主題文には通用しない。

…と思う。単文分割の方が重要な課題に思えてしかたない。

CREST プロジェクト的には、まずい方向に議論進んでしまっている。
ケンカを売らないオチを早く見つけないと。

*  svm_struct [r]

複数ラベル対応とCFGバージョンが公開されているよ、とのこと。

http://www.cs.cornell.edu/People/tj/svm_light/svm_multiclass.html
http://www.cs.cornell.edu/People/tj/svm_light/svm_cfg.html

Kしまさんに教えてもらった。ありがとうございます。

* crf [r]

crf.sourceforge.net の CRF の実装を試してみた。

昔のバージョン(1.0)は、入力データや config ファイルをどうしたらい
いか予想できなかったが、新しいバージョン(1.1) samples というディレ
クトリができていたらしい。知らずにいた。ダメダメ。

java と ant は前にインストールしておいたから、README の通りにコマ
ンドを打つと、普通の crf は動いた。
でも、semi-markov にするところは、激しく、敗北。

* 続 EM チュートリアル [r]

yet another T レク。疑問点を解消。でも、まだ不安定な実装のまま。
それより、アラインメントという問題が、私の中で、混沌としてきた。
まずいなぁー。

* Dan Melamed [r]

完全に敗北です。あなたのすばらしいと絶賛されている作品は、私には、
全く理解できません。

学生時代、あんまりわからなかった Alshawi や Brown の論文だって今は
ある程度イメージがつかめて理解できた気分になっていますが、あなただ
けは別格です。学生時代読んだ論文を、何度となく再読してもわからない
し、本もわからないし、最近発表している論文もわからない、です。くや
しいですが、一部のショートペーパーを除いて、煙に巻かれたままです。

むぅー。Kevin Knight ぐらい、難解なことでも平易に表現してくれない
と十分に理解できない、私の受信能力に問題があるんだが。Dan Melamed
には自明なことでも、凡人の私にはわからんのだぁー。

* EM 実習 [r]

aspect model は、くどうくんの PLSI モデルと同じ結果がでているよう
だ。optimization や refactoring は後回し。（気が向いたら）
TODO: sparse matrix, random generator, 数学公式周り。

動いてはいるんだが、いくつか未解決なことが。

分からないこと I - モデル学習のときは、 P(d|z) を推定して出力され
るけど、それと同時に、"inverse" prob として P(z|d) も出力できる。
P(d|z) が old の行列(推定値)を出力しているところまではわかるんだが、
P(z|d) は current の P(d|z) の行列を転置したものを出力している。
current を使うのはいいとして、転置しただけで、p(d|z) --> P(z|d) と
いう解釈になる理屈が、自分で考えられない。

※ メモリ流用している部分のコードを勘違いしていた。

分からないこと II - gain の計算と収束条件。なんとなくわかった気に
はなってみたが、まだ、だまされているような。

※ 最初は、最尤推定みたいな値と入れていた。

product model は、細かいところで予想通りトンザした。隠れ変数の共起
確率 P(u,v) の初期値は、一様分布でいいんだろうか。P(d) や P(w) は
どうやって求めるんだろうか。aspect の場合は、P(d) = P(d|z) * P(z)
でいいのだが、product の場合は、P(d) = P(d|u) * P(u) となるけど、
推定しているモデルは P(u,v) だから、P(u,v) から周辺確率 P(u) を求
めるのでいいのだろうか。

* EM チュートリアル [r]

T村先生に教えてもらう。Q 関数のココロを教えてもらう。
実装する上で、EステップとMステップのポイントを教えてもらう。
そして、一番苦手な頭を使う手計算(ラグランジ法を含む)にも、おつき合
いいただく。多謝。

＃ 自力で偏微分ができない私が悪い？！ すこしは成長しろって。

* wamf [r]

PLSA に熟知されておられる T 助手に、私の妄想を聞いてもらう。大域的
な言語モデルと文レベルのアラインメントを同じレベルで扱っていいのか、
そこがフニオチナイ、と言われて、なるほどと納得。確かに、文レベルで
の joint distribution (data matrix) は missing values だらけだし。

あの論文は、non-negative matrix factorization であればなんでもいい
訳で、PLSA を適用するための正当化 (justification) は特になかったよ
うな気がする。と返答しつつも、T 助手の指摘はマットウで、やはり、モ
デルとその解釈をしっかり詰めておかないと、気持ち悪い、ことを実感さ
せてもらう。感謝。

今の私は、EM の基本を押えていないから、細かい話についていけない。
ということで、wamf はちょっと置いといて、当面は、EM の理解を深める
ために時間をさくことにする。

* wamf [r]

一通り動くかせてみたけど、CREST データのような短文でも全滅。

初期行列(contingency table, co-occurence data, joint distribution)
で推定量を使うが、これが、あまりにも貧弱であるような気がする。

隠れ変数の使い方のコツも掴めていないし…。

* wamf [r]

PLSA と AIC などの基準について、某助手さんに質問する。

やっていて思うことは、alignment の数(潜在変数の数)をあらかじめ指定
してモデルを学習するのだが、そこが、なんとなく単語アラインメントの
タスクとずれているような気がする。一番難しいのは、alignment の数を
決定することだし…。

彼の突っ込みは、最初の co-occurrence data だけから出発するのが気持
ち悪い、だった。そこの意識も共有できるけど、ま、いろいろな工夫は、
わりと容易にできると思う。

なんとなく、Aspect model と Product model のことを指して、あーでも
ないこーでもないとイメージしていたが、それはこういう名前があります
よ、と教えてもらった。ちょっと、すっきり。感謝。ただ、もう少し考え
ないと、整理つかない。

今日は、夏休みで人が少ない通勤列車で、↓を読む。

http://www.cs.brown.edu/people/th/papers/HofmannPuzicha-IJCAI99.pdf

終らなかったので、きっちり長津田で降りて、喫茶で続きを読む。乗り過
ごさなくって良かった。以前のように町田まで往復するなんて、辛すぎる。

どうも、Aspect model の方がモデルがしやすいとか、精度が良い、とか
書いてあるが、これは適用する問題に依存するような気もする。それより、
わからない言葉と式で、理解できない。Variational EM（変分ベイズ法？）
とか mean-field approximation （平均場近似？）とか、聞いたことある
かもしれないが、実態はさっぱりわからんコンセプトばっかり。悲しい。

昨日、ぼやいたけど、どちらのモデルでも z の数なり、クラスタの数は
予め指定してしないと学習できない。フリダシニモドル。

* wamf [r]

http://acl.ldc.upenn.edu/acl2004/main/pdf/187_pdf_2-col.pdf

行列の分解を PLSI で近似しているけど、他にも考え方があるように思う。

対訳文は、二部グラフの隣接行列で、グラフの分割をすればいい。
＃ ひょっとしたら、他のグラフの行列表現方法の方がいいのかなぁ。

Dekai Wu がちょっとだけ披露した translation-driven segmentation の
ように、top-down でアラインメントとるのであれば、recursive に
spectral graph bi-partitioning でいいような気もするけど。カットを
考えて、cross しているやつが少ないようい分割する。乱暴かな。

ただ、あの論文や Alshawi の論文だって、phrase structure か
dependency relation かという違いはあるけど、ある pivot word とその
周辺が正順か逆順かという判断を学習させながら parsing しているよう
に思う。こういう正攻法も捨てがたいけど…。どうだろうか。まあ、彼ら
の問題意識は、デコードを視野にいれた翻訳モデルにあるだろうから、単
に、アラインメントデータ作成という動機とは違う。そこんとこ押えてお
かないと。

行列は、グラフの表現形式だから、その辺りを考えれば、面白い関係が見
えてこないかあ。いずれにしても、one more twist が欲しいところ。

とりあえず、こういった議論を展開する上で、私は、線形代数ですでにわ
かっている行列の性質を知らなさすぎる。修行せねば。

* GIZA++ [r]

atsush-f さんが日記で、inverse translation probability を解説してくれてる。
私が、勘違いしていた箇所も、謎解きしてもらった。感謝。

原言語は fr で考えるのね。そうだった。

* wamf [r]

word alignment を matrix factorization でやろうという論文の細かい
ところを理解すべく、ここんとこ、reverse engineering に励んでおりま
す。頭の回転も手も遅いんで、まぁ、ぼちぼちといったところ。

100-best alignments を decoder で出力して、関連度行列を作るところ
は、ずるして、test data を IBM 4 で学習して、translation table を
得る。これを両方向でやって、log で適当に整数コストに落とす。まあ、
ここは、いわゆる辞書をそのまま入れてもいいと思うし、対訳ペア抽出で
算出した重さを入れてもいいから。

さて、PLSI は、くどうくんのパッケージを使わせてもらう。どうも、入
力データ準備にバグがあったみたいで、悩む。どうしてもわからなかった
から、T村さんに聞く。問題の箇所を的確に指摘してくださる。列でみた
とき、使われていない素性が混入していたみたい。足すと１にならない、
と実装上困るでしょう、といわれて、納得。助けてもらって、やっと学習
してモデルができる。ふぅー。

で、あとは、最大の cept を選んで、行列の積をとった。結果は、うーん。
よくわからない。cept の数をあらかじめ決めておかないとまずいんだか、
これは、入力依存だし、この辺りのコツがつかめてない。

* MeCab [r]

くどうマジックで、C API が通らなくてセグフォになるところを対処して
もらう。ごく一部の用途でしか N-best はいらないから、これでいいと思
う。ありがとうございました。

いつも、*.so ファイルと ldconfig 周りで、ぼけたことをしてしまう。
今回も、

新しい libmecab.so をリンクしていますか？
env LD_LIBRARY_PATH=../src/.libs ./a.out

していませんでした。ごめんなさい。

* decoder [r]

N-best candidates を出力するのには、decoder が必要だという自明なこ
とに、今気づく。ボケボケ。

誰か、decoder の情報をお持ちでしたら、教えてください。どの論文が比
較的親切とか、ネットのどこに落ちているとか (ISI ReWrite
http://www.isi.edu/licensed-sw/rewrite-decoder/ 以外)、なんでもい
いので、お願いします。

MT の最近の動向は、よくわからない。COLING が始まる前に、ACL を制覇
しないと思い、読んではいるが…。NAACL より、SMT 以外にも少し門戸を
開放している感じもするけど、どうなんだろう。２年間、bioinfo な世界
にいたから、もう、謎だらけ。道のりは長くて険しそう。

やっぱり、デコーダーは、永田さんの教科書や渡辺さんのD論でも読んで、
自分で作るしかないかな…。ソースコードがないと理解できないから。

* GIZA++ [r]

GIZA++ の translation table の値を使いたいのだが、
e2f.t3.final と e2f.ti.final は、何を出力してくれているんだろう。

学習の時は、

$ GIZA++ -T sample_vcb.fr -S sample_vcb.en -C sample_snt.ef

としたが、(e が source で f が target の意)、
学習された e2f.t3.final はどの確率を指しているんだろう。

Each line is of the following format:

s_id t_id P(t_id/s_id)
where:
 s_id: is the unique id for the source token
 t_id: is the unique id for the target token
 P(t_id/s_id) the probability of translating s_id as t_id

とあるのだが、e2f.t3.final は、P(f_i|e_j) でいいの？
あと、inverse probability table は何者なの？
何を inverse したの？ どうやってあの値を計算したの？

じぃーっと、データをを眺めてみると、

e2f.t3.final の一行目

0 3 4.1079e-07

e2f.ti.final の一行目

3 0 1.21181e-05

e2f.actual.ti.final

$ NULL 1.21181e-05

とある。e = "$" で f = "NULL"。ということは、source が e で、
target が f と仮定した場合、

e2f.t3.final は、P(f_i|e_j)
e2f.ti.final は、P(e_j|f_i)

ということらしい。なぜ、inverse だけ、文字列変換しているのか、謎。

識者の方々、GIZA++ の出力の意図を教えてください。

* やっぱり完全アラインメントよね [r]

４月の GB で所信表明したように、『完全アラインメント』課題を取り扱
おう。前からやってみたかったことだし。

とりあえず、F田くんに発表スライドを譲ってもらった XREC からの論文
を再読。行列での表現方法、その分割問題になる、ってところまで、３年
前からなんとなく考えていたことと一緒。こうやったら解けるんだー、目
から鱗。なんだか、嬉しい。

しかし、細かいところでつまずく。LSA の説明で、隠れ変数の数 (c) を
どうやって求めているか分からなかったから、T村キャプテンに質問。
「テキトーです。実験を重ねて最適なところを求めるんです。基準として、
AIC、BIC、MDLみたいなのがあります。」らしい。疑問解消。さすが。

やっぱり、センスとノウハウは日頃から磨いておかないと、と思った。

* 参加して良かったこと [r]

1. marginalized kernel が、頭の中でイメージができるようになったこ
と。

つぼいくんの発表の時のK沢さんのコメント。となりに座っていた、S木さ
んのミニ解説。休憩時間に、くどうくんとつぼいくんにも、いろいろ。

私なりに表現してみると… ある場所で平均場近似しながら損失を取り込
みながら学習して、デコードの時は、前後を考えずに、Viterbi-like で
ベストパスを見ればいい。

marginalized しているから label bias も起こらないし、カーネルでき
るらしい。任意の素性の畳み込みができるらしい。で、loss function は
その場所、その場所での平均場近似をしているから、point-wise の方が
都合が良いらしい。

K島さんの説明を読み返してみると、なんとなく、わかってきた。これで、
例のネタにパクつけそう。

2. max-margin parsing と svm_struct の論文が、前より、だいぶ、分かっ
たこと。

休憩時間に、くどうくんに、max-margin の論文のトリック
primal->dual(alpha)->primal(rule) のところの極意を説明してもらった。
多謝。あれは、損失関数をあのようにしたから、exponential -> cubic
に計算を落せるということらしい。一般的に、exponential 制約について、
解消しているわけではないらしい。

3. EMNLP のくどうくんの発表を、動画で、S木さんにみせてもらったこと。
＃ テレビがない生活をしていると、動画に異常な感動を覚える。

その他、S保さんから、グラフ関係の話を聞いたり、F田くんから、
statistical MT の細かいところについて教えてもらったり、有益でした。

総括すると、とても有意義な時間を過ごさせていただきました。
ありがとうございました。

ちなみに、私の発表の ppt に、図やアニメーションは一切なかった。
絵ゴコロがないので…。あしからず。
そうしたら、F田くんが、アニメーション ppt を恵んでくれた。
修行させてもらいます。

* なんとか準備する [r]

本当は、違うことを喋ろうと思っていたが、準備不足で断念。
でも、風邪は、なんとか快方に向かっているかな？

けいはんな地区には、形態素解析や機械学習が得意な人がいるから、率直
な意見を聞きたかったのに…。

* svm_struct [r]

半分も理解できない論文のネタ、その二。

I. Tsochantaridis, T. Hofmann, T. Joachims, Y. Altun,
"Support Vector Machine Learning for Interdependent and
Structured Output Spaces", ICML2004.
http://www.cs.brown.edu/~th/papers/TsoHofJoaAlt-ICML2004.pdf

理論はさっぱりわからないが、この論文を基にしている svm_struct とい
うパッケージが、Thorsten Joachims のページからダウンロードできる。

http://www.cs.cornell.edu/People/tj/svm_light/svm_struct.html

実験のところで、NER や Parsing にも適用していて、面白そうだったか
ら試してみたくなった。struct_hmm や struct_pcfg は coming soon だっ
たけど、配列アラインメント(懐かしい…) svm_align はダウンロードで
きる。

http://www8.cs.cornell.edu/~paz3/svm_align/

svm_struct は、関数のインターフェースを提供しているだけで、
svm_align で、具現化するという関係になっている。

動かしてみることができれば、実現方法を調べてみることで、理論がわか
らなくても、すこしはイメージがつかめるとっかかりになるかな…と思い、
試行錯誤してみた。が、激しく、敗北。(ま、expected outcome ですが。)

簡単な敗北ログを。

# コンパイルができない！

+ svm_struct の方のパッケージに svm-light が含まれているが、 QP
solver を使うのではなく、svm_align は、 PR_LOQO optimizer を使って
いる。インストールのやりかたは、
svm_light
のページに注意書きがある。

+ Makefile や #include のところで、 svm-light と svm_light という
２つの書き方が混在していている。要チェック。

+ svm_align をコンパイルするときは、bin と tmp というディレクトリ
をあらかじめ用意する必要がある。src に svm_struct のコードと、
svm_align.tar.gz から svm_struct_api.c, svm_struct_api_types.h,
svm_struct_classify.c を用意する。

+ コンパイル中にも警告がいろいろでる。(不安度向上へ抜群の効果あり)

+ 実は、svm_struct_api.c, svm_struct_api_types.h で関数のインター
フェースと実装が矛盾している箇所がある。

# segmentation fault になる！

$ ./svm_struct_learn ../example.data ../example.mdl
Reading training examples...done
セグメンテーション違反です

私だけの幻想か…。ここで、ハッキングする根性がなかった…。機械学習
への愛も足りないだろうし、日頃の行ないも悪いからか。

もっと修行しないとダメですね…。

* GIZA++ [r]

世の中の statistical MT と word alignment model とはどんなものなの
かを調べたいんだが、いまいち結果の解釈ができない。

ALIGNMENT FILE (*.A3.final) という結果ファイルの一部を眺めて、学習
中の Viterbi alignment がどうなっているか観察しているのだが、なん
だか、信じられないぐらい性能が悪いように思う。謎。

* 重文と複文 [r]

555 文ほど、因果関係の構文ファイルがあったので、眺めてみる。
和英辞典から抜き出した文だからか、不自然な英訳が散見された。
＃ 忠実な訳というのとは違う。おさまりが悪い英文。

熱で意識が半分とんでいたけど…複文の主節(核)と従属節(衛星)だってひっ
くり返して訳しても通じるじゃないか疑惑発生。頭から訳出する方法とか、
通訳訓練でやるスラッシュリーディング、とかは、談話レベルでの節の関
係を無視しているんじゃないかなぁ。と、とりとめもないことで時間切れ。

アラインメントには、重文か複文か単文かという分類や他の意味的な分類
をバイパスする方法が存在するかも、とか思ったり。

* 雑談ミーティング [r]

とてもお疲れの奥村先生と、雑談ミーティング。

悩みつづけていた、今年度の私のCREST関連研究のオチについて、どの辺
りに設定すればよいか、という疑問が解消した。CREST プロジェクトや奥
村先生から期待されていること、が明確になった。向かう方向が分かった
のが、最大の成果。よかった。一安心。

以下、将来の私へのメモ。

- 重文と複文の訳し分け（言い換え）についてつながる研究であって欲しい。
- 研究の出発点は CREST 生データからで良い。
  CREST 以外のデータ(web からもってきたデータ)も利用してよい。
  例の語彙体系を拡張したパターンファイルに限定されなくてもよい。
  このデータは、評価用として利用して、いろいろ考察をする方が嬉しい。
- 研究は、分野できちんと評価されるものに仕上げるようにする。
  CREST チーム内でしか通用しない発想や方法論は、むしろ、好まない。
- 夏休みの宿題は、例の妄想ネタで良いみたい。

* JBI [r]

Special Issue の guest editor から、of publishable quality だ、と
連絡がくる。多分、これで、採録。手続きとしては、これから、JBI の
editors による査定があるらしい。ふーん。

十数ページにもおよぶ査読コメントを直したのが評価されたのか？こっち
も一週間ぶっ通しで直したから疲れたけど、editors も読むのに疲れたみ
たい。今回の直しは、私のお粗末な冠詞の言語モデル周り。"a" と削れ、
"the" を入れろ、という指示が 80 % 以上だった。違う神経を使って、妙
に疲れた。Viterbi algorithm の前には "the" を入れて、Double Array
の前には "a" にして、"F-measure" の前は "an" っていう。すっかり混乱。

アメリカ語では、"envisage" を "envision" というらしい。へぇ〜。

* 部分木マイニング [r]

2 年越しの課題だったけど、やっと、部分木マイニングに挑戦しはじめる。
とりあえず、依存解析木を対象としたいから、兄弟関係は考慮するが順序
は考慮しない unordered 部分木マイニング。

http://www.i.kyushu-u.ac.jp/doitr/trcs216.pdf
http://www.cs.ucla.edu/~ychi/publication/cmtreeminer_pakdd04.pdf

まだ具体的なイメージわかないんだが、なんとなく、分かったこと。

- equivalence class を定義するために、cannonical form を導入する
-- depth-first cannonical form が rooted (un)?ordered (maximal|closed)? subtree mining の標準的なデータ構造みたい。ポイントは、最右拡張。
-- breadth-first cannonical form にすると、free tree マイニングへの拡張が比較的容易にできるらしい。
- maximal と closed の違い

基本的には、「姉--妹」関係と「先祖--子孫」関係の両方がマイニングで
きるようになるのだが、どっちの関係が結果を左右してしまうのかな？

1960-80 年代のコンパイラの研究成果に多謝。ドラゴンブック最強。

* リハビリ明けなのに、いきなりスランプ [r]

候補パターンを系列マイニングでのネタが、なかなか軌道にのらない。

私の BIDE の実装がヘタレだから、マイニングに一週間かかっている。
sequence database のサイズが 127,813 で、100 回以上出現したもの(
データマイニングコミュニティでいうところの minsup 0.0776 % ) を対
象にしているから、そもそも無茶なのかも。どちらかというと、sparse
な sequence database だと思うけど、その基準はよくわからんし。むぅー。

とりあえず、374 文しかない小さな The Happy Prince で精度を計算する。
ちなみに、ここでいう精度は、抽出されたものが分母で正解と人手で判断
したものが分子。unannotated & unsupervised な設定だから、正解コー
パスがない。リコールを測定するのは、無理。

最低出現回数 は 2 で設定。結果はイマイチ。BIDEの精度 は、
118/207 で 57% 。PrefixSpanの精度 は、121/271 で、45% 。目視
のレベルだけど、BIDEの抽出結果 と PrefixSpanの抽出結果 を
比べると、BIDE の方が、同点スコアによる誤り対応が少なくなって、
それなりに、順序よく抽出してくれてると思うが。たいしたことない。

部分木も試しておきたいな…。実装から始めないと…。時間あるのか？

＃ で、CREST の研究、どうしよう。アラインメントは、いつするんだ？
＃ 棚上げした cocab はどうすんの？ 制約、タグとばし、ごちゃまぜ、多言語…
＃ … … … 山積み。激しく、落ち込む。つぶれそう。こげまくり。

* BIDE [r]

一から、クラス構成を考え直す。実装がやっと固まる。
今日も、何度か、(バカ)正直な奴に八つ当り。
動くんだが、出力が期待通りじゃない。シューん。

* GIZA++ [r]

先週の水曜日の勉強会のときに、話題に上がったので、GIZA++ を試してみました。

% make -f Makefile depend
% make -f Makefile all INSTALLDIR=/home/lr/kaoru/bin

2003-09-30 のバージョンは、gcc-3.3.3 (Debian) でもコンパイルできま
した。

% GIZA++ -S S.vcb -T T.vcb -C ST.snt

で動くんですが、vcb (Vocaburary file) と snt (Bitext Files) サンプ
ルがなかったので、The Happy Prince の 374 文から、適当にファイル整
形をして、GIZA++ を動かせてみました。出力

中身はよく分からずに、動作させているから、いろいろ工夫するともう少
し賢そうな結果になると思う。（あれだけ論文が出ているんだから、統計
的機械翻訳の実力はこんなものではあるまい。）

* BIDE [r]

実装で、泥沼にはまる。（いつものこと）

* BIBE [r]

論文の書き方がややこしくてわからんかったが、英語の between the end
of A and B と after A and before B は同義っぽい。定義をかなり勘違
いをしていたことが発覚。示している部分文字列に A と B は含まれない。

A|<--- 部分文字列 --->|B

なんとか、Ruby での実装が終りそうなところで、論理バグで、沈没。
last_instance が見つからないという例外処理がうまく機能していない。

＃ あぁー、プログラミングセンスないよなぁ ＞ 私。

論文のどこにも書いていないけど、実装は、last_in_last と
last_in_first は cache しておいた方が良さそう。
富豪的プログラミング、万歳。

* 学辞郎 [r]

Sせんせとの仕事での英単語コア辞書が欲しい、と切望していた。コアな
ら学習用辞書よね。ってことで、学辞郎をインストール。

収録されているのは、アルクが開発した「標準語彙水準12000」
（SVL=Standard Vocabulary List）。一覧。

・レベルが１２？段階ぐらいに分かれている
→ NTT の単語親密度？みたいに、利用できるかも。

・品詞、単複、活用形の情報がある。
→ 専門家がチェックした正確な情報は、言語処理屋にとって有用。

・学習用なので、ゴミが少ない。

というご利益があるのだが…。学辞郎には、辞書本体がテキストデータに
なっていなかった(泣)。しゃーないので、リバースエンジニアリング(正
規表現を根性で書く)。無駄な頑張りであった。

＃ 変換スクリプトは、恥ずかしくて公開できない。v.65 しか動かないし。

* BIDE [r]

高速化は後回しにして、アルゴリズム理解のために、Ruby で実装。

* BIDE [r]

このアルゴリズムは、backward extension に関する観察が優れている、
と思う。実装は、インデックスが 0 始まりにするようにしないと。

* BIDE [r]

NL 研で、つぼい君が、CloSpan は、scalable ではないから使えない！と
いう最もな指摘をしてくれた。それと、新しい論文出てますよ、ってこと
で、BIBEを読む。CloSpan との違いを簡単にまとめると

1. マイニング途中経過を保持する必要がない。CloSpan は、あるパター
ンが吸収できるかどうかを判定するために、過去に発見したすべての
closed パターン(候補)をラティスで格納していた。

2. 系列は、すべて、１つのアイテムから構成されるアイテムセットと割
り切った。つまり、I-step extension を切り捨てる。

強調すべきは、1. の "without candidate maintainance" で実現したこ
と。S-step extension のみと限定した場合における拡張を forward
extension と backward extension にさらに分類して、吸収されるか否か
の判定ができる性質を見出したこと。

＃ I-step extension が扱えるような拡張は容易とあるが、本当？

* 構造化データを対象としたマイニング [r]

http://hms.liacs.nl/index.html は、まとまっていると思う。
くどうくんの FREQTの実装もリンクしてあるよ。

* 環境整備、諸々 [r]

週末のおよばれの時、たつをさんが学辞朗をくれた。これが、Sせんせ
＠JAIST との仕事で必要なコア辞書に使えそうと思いたつ。学習用辞書だ
から、ゴミがない（はず）。英辞朗と同じように、テキスト形式の辞書デー
タを探す。が、見つからず（泣）。やっぱり、売りモノだからバイナリら
しい。

そういえば、Reuters Corpus を web 越しで注文したんだが、返事がこな
い。どなたか、具体的な入手方法をご存知ですか？ 早いこと、固有名詞
タガーを yamcha で学習してしまいたいんだが。

そろそろ、奥村研で、英語を処理する環境を整えないと。

* NL研 [r]

熱い議論もあったし、関西方面から有名人がきていたので、それなりに盛
り上がった、と思う。
個人的には、磯崎さんの仕事（優先度学習）がヒット。
Penn Treebank II と III は、同じディレクトリ構成らしい。
お昼は、５人で食べにいくが、席の関係で、ボスと２人席にすわる。
「最近、どうですか？」を発言したきり、ひたすら、聞き役にまわる。
ボスは、あいかわらず、ご多忙の毎日のようだ。

* CloSpan [r]

一応、紹介する。くどうさんの prefixspan の実装は、itemset
extension を考慮していないから、注意してね、っていうと、翔ちゃんか
ら、itemset extension が必要な場面が思いつかない、とか質問される。
itemset で形態素の属性をすべて格納できるから、便利だと思うけど。

* PrefixSpan と CloSpan [r]

明日紹介する予定の CloSpan を読みながら、以前、書き方が曖昧でよ
く理解していなかった PrefixSpan の itemset と item の違いが、やっ
とわかった。元論文より、はるかにわかりやすい。

パターンを拡張するのは、2 つある。一つは、パターンの末尾に、1 item
から構成される itemset を連結する場合で、もう一つは、パターンの末
尾の itemset に item を入れる場合。前者を sequence extension
(S-step extension) 呼んで、後者を itemset extension (I-step
extension) と呼ぶらしい。Bayardo の Set Lexicographic Order の考え
を拡張して、Sequence Lexicographic Order というのを定義してやると、
それに対応する prefix search tree ができる。実際のマイニングは、こ
の探索木を depth-first に構築していることになる。

私は、いままで、S-step extension しか念頭においていなかったような
気がする。S-step extension と I-step extension という考え方は、
Aryre の
bit 操作でマイニングを高速にする論文から踏襲したらしい。ということ
で、実装方法について、あれこれ、考えてみる。ゼミがあったりで、まだ、
未完。

話を CloSpan にすすめると、Zaki の TreeMinerV でも、この CloSpan
もそうだけど、candidate generation をするときに、equivalence class
をどのように定義するがミソ。CloSpan の論文では、共通の接頭辞や半順
序の性質などいろいろ試行錯誤した結果、projected database の item
のべ数によって、equivalence を保証したみたい。この性質を利用して、
探索空間の枝刈りができる条件を導出してる。実際には、prefix search
tree で non-closed な枝を merge して lattice にしておく。重複して
いる部分木を移植したイメージ。この操作を「吸収」(absorb)というらし
い。

ここまでは、わかったんだが、実装の記述で煙に巻かれた。projected
database の item のべ数を key としたハッシュをデータ構造にしている
んだが、なんかね、ちょっと無駄な候補も生成してしまうらしい。だから、
ハッシュの key について、代替案を述べているだが、わけがわからなく
なる。あと、non-closed sequence じゃないものを prefix search
lattice から削除するステップがわからん。Zaki の diffset がどうのこ
うのとあるが、あれは、basket mining の話じゃないのか？！ 謎深まる。

＃ 明日、大丈夫かな？

* length bias に関する質問 [r]

うぅぅぅ。どうしよう。

* debian と g++ (3.3.3) [r]

flex に続いて [2004-04-13]、mecab (ruby|perl) binding でも、すんな
りいかない。gcc (3.3.3) gcc-3.2 gcc-3.0 gcc-2.95 でも、C API がセ
グメンテーションフォルトになる。号泣。

* The Happy Prince [r]

日本語文に出現する半角スペース問題 [2004-04-27] が、解決。ふー。
MeCabの codeconv.h, tokenizer.h, を参考にさせてもらう。とくに、
skipCharClass 関数は、かゆいところへ手が届いてくれて、感激。

子文字変換し忘れ問題 [2004-04-29] は、当方のコーディング能力欠如の
ため、汚く解決。メモリーリークは、未決。

修正した結果とおまけ。前回よりもゴミを多くひろっているかも…。

* Sせんせ＠JAIST [r]

メールがありました。かなりマトモな時間帯に受信したみたい。そのこと
に驚く。

こっちはまだ敗北中だけど [2004-04-14] ここらで、cocab (crfバージョ
ン) のデバッグを完了して、区切りつけよう。taku-ku さんの発表に間に
合うと、いくらか恩返しになるんだが。いくらなんでも無理そう…。

次は、せっかく、Web データの扱いに詳しい奥村研にいるから、S先生の
もともとの興味に近いテーマにしたい。PubMedやその他ウェブに転がって
いるテキストデータを力業でつかいこなして面白いことできたぞ、という
方向性になれば、お互い、幸せ。多分。
(大岡山にいるシニアな方が邪魔しなければ、という条件が…。)

* The Happy Prince [r]

お馬鹿な文字列検索だけで、どういう対訳がとれそうか、試してみる。い
ろんな意味で詰めが甘い近似結果でしかないけど、抽出されている種類が
異なる。

頻度を手がかりにする[2004-04-22]。
辞書を手がかりにする。

あっ、辞書って、子文字でしか登録されていないから、case insensitive
な検索にしないとまずいよな…。今、気がつくなんて…。

* The Happy Prince [r]

とりあえず、見かけ上の単語区切りという概念を取り払って、単純に(お
バカに)辞書を文字列検索( da.commonPrefixSearch() ) して、単語レベ
ルの対訳関係を見つけることができそうか、やってみようとする。

でも、日本語文に出現する半角スペースで、激沈。うぅー。

* The Happy Prince [r]

EDRから辞書を構築。Darts辞書にするところまで。

* The Happy Prince [r]

内山さん＠NICT が公開している幸福の王子 に対訳表現抽出をやっ
てみました。全部で 378 文ありました。少量のコーパスなので、自立語
だけで対訳系列を作って、マイニングは連続 n-gram だけを対象にしまし
た。具体的なパラメータは、最低 2 回以上出現して、系列パターンの長
さを 3 までに区切る。(サポート 2、長さ[1,3] ) 要するに、北村モデル。

上位はこんな感じ。「王子」と「言い」が既に抽出されているから「王子
言い」ってのは冗長に抽出されているというツッコミが…。

163.457 Prince|NNP 王子|名詞-一般
126.646 said|VBD 言い|動詞-自立
88.3962 Swallow|NNP ツバメ|名詞-一般
81.9171 Happy|JJ Prince|NNP 幸福|名詞-形容動詞語幹 王子|名詞-一般
81.9171 Happy|JJ 幸福|名詞-形容動詞語幹 王子|名詞-一般
68.2913 said|VBD Prince|NNP 王子|名詞-一般 言い|動詞-自立
66.482 Egypt|NNP エジプト|名詞-固有名詞-地域-国
55.6727 statue|NN 像|名詞-一般

いわゆる、頻出しまくりな単語を含む系列(Swallow|ツバメ)や頻度による
類似度が同点の場合(Town Councillors|市会議員)、問題。要検討か。

50.1805 Swallow|NNP Swallow|NNP little|JJ ツバメ|名詞-一般 ツバメ|名詞-一般 ツバメ|名詞-一般
50.1805 Swallow|NNP Swallow|NNP little|JJ ツバメ|名詞-一般 ツバメ|名詞-一般
50.1805 Swallow|NNP Swallow|NNP ツバメ|名詞-一般 ツバメ|名詞-一般 ツバメ|名詞-一般
50.1805 Swallow|NNP Swallow|NNP ツバメ|名詞-一般 ツバメ|名詞-一般
46.7377 city|NN 町|名詞-一般
44.358 answered|VBD 答え|動詞-自立
40.2162 river|NN 川|名詞-一般
38.2899 Councillors|NNPS 議員|名詞-一般
38.2899 Councillors|NNPS 市会|名詞-一般 議員|名詞-一般
38.2899 Councillors|NNPS 市会|名詞-一般
38.2899 Town|NNP Councillors|NNPS 議員|名詞-一般
38.2899 Town|NNP Councillors|NNPS 市会|名詞-一般 議員|名詞-一般
38.2899 Town|NNP Councillors|NNPS 市会|名詞-一般

全部で 242 個抽出されてました。実行時間は、対訳系列を前処理で用意
した時間を除くと、0m0.376s です。正解率はどのくらいなんだろう。と
いうのと、ほとんど、英辞郎に掲載されているのでは、という懸念が叫ばれています。

* 次世代なのか？ [r]

対訳君は、ユーザの観点からみると、使えるものなのかもしれない。

* アラインメントの類似度 [r]

というか、アラインメントの表現と評価で悩む。
表現は、なんとなく決着。評価は、未決。

* 対訳アライメントのデータ作成 [r]

* 偏微分リベンジ [r]

高村さんに、押えるべきツボを教えてもらいました。感謝。

* 偏微分でも敗北 [r]

コーデイングが飽きたから、ME の Lagrangian で、primal から dual に
するところを頑張ろうと思ったが、ビセキの基本をおさえておらず、敗北。

* emozc でも敗北 [r]

今週は、月末のドタバタで封印していた、コーディングをしている。
maxent の部分の使い方はなんとなく習得。
でも、その他の部分でセグメントフォルト中…。

* flex で敗北 [r]

昨日の敗北のつづき。どうも、g++ がまずいみたい。gcc だと問題ない。
ということで、c の関数にして、cpp 側で extern "C" で呼び出して、
wrapper 関数を書くのが良いのがいいのかな。

* 敗北 [r]

なんだか、redhad 上で flex から生成されたコードが debian 上で走らん。
おんなじ、gcc 3 系の compiler だと思うけど…。
今日は、疲れたから、追跡は中止。

* CREST データ解禁 [r]

見てしまった。力業だ。
S先生＠NAIST もそうだけど、N社にいるとアメリカンな発想になるのか。
それより、方向性だけでも考えておかなと、やばい。

* 再実装 [r]

* 時間切れ [r]

前処理しかできてない。しかも、報道系だけ。間に合うのか？

* インストール [r]

Uさん＠NICT (CRL) さんが公開されているツールをホームにインストール
する。「標準的な」英語の処理環境は、簡単にできてしまった。多謝。

＃ cocab は使うけど、一般英語の場合、わかち書きの曖昧性は稀だから
＃ あんまり必要なかったりする。

* 敗北 [r]

データ整形 - 例外につまずく。
ソースコード - 動かない。

* 無料で入手できそうな対訳コーパス [r]

オープンソース系
http://logos.uio.no/opus/
新聞系
http://www.mag2.com/m/0000089609.htm

* tools のインストール [r]

つかれた。未完。