最近の（でもないけれど）出来事／落書帳／仲間内のネタ／覚え書き／whatsnew

Tue,31 Mar,2009の、 anthy-9100h + alt-cannadic-090308 + alt-depgraph-090308 の蛇足の話（間違いではないし、訂正すべき物でも無いけれど、 かといって最適というわけでもない微妙な付属語が出現してしまう話）。
「vagus氏 - 丘の道を登り - 2009年04月03日 - 自作 depgraph 更新(4/2)」 にて、解説がありました。有り難うございます。
結局、行き着く所は、 コーパスを10倍100倍に増やすとか、 新しいエンジンを開発するとか、 になってしまうかなぁ。
すみません、良いあるいは良さそうなアイディアが浮かびません。

anthy-9100h.patch13Bptn20 のバグ。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
ENABLE_ERROR_RECORD を有効にした時に、 ごくまれに判定ミスがある事に気付いた。
送り仮名のパターンが複数有る単語を学習してある場合に、 判定を間違えている。
例えば「おこなって」を変換した時の「行なって」と「行って」だと、 システム辞書で先頭に載っている「行って」だけ処理を行い、 それ以降に載っている「行なって」の判定は行われていなかった。
まぁ、実用上は問題無いのだけれど。治した。
Mon,13 Apr,2009に続く。

anthy-9100h.patch13Bptn20 のバグ、 Sun,12 Apr,2009の続き。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
そのせいで、システム辞書で先頭に載っている物以外には、 LATTICE_AUTOEXPAND_DEPS も適用しなくなっている事に気付いた。
治した。

uim-anthy で 文節区切りを明示的に指定しながら入力する入力方法。
たぶんThu,04 Dec,2008の続き。
以前、 「芝玉ブログ - 2007年1月14日 (日) - 文節区切りを検出するには?」、 「丘の道を登り - 2008年12月02日 - 自作 depgraph の進捗状況」、 辺りで見かけた、 uim や Anthy において、 文節区切りの位置を人間から取得すれば変換結果が良くなるのではないか、 と言う話。

↑ 唐突に、１〜３日前後で使い始める所まで持っていける実装方法を思い付いた。 思い付くも何も、取っ掛かりが掴めれば、わりと簡単な実装なのだけれど。
uim のキーマップを変更して、 「(文節区切り指定キー) (かなの入力)」と入力した場合は 片仮名が入力される様にする。 あとは anthy の文節区切り抽出のアルゴリズムを、 片仮名／平仮名で区切り位置を判定するアルゴリズムに交換する。 前方ｎ文節なアルゴリズムを実装するよりは簡単。
何か適当なキーでカタカナが入力される様にしたり、 シフトキーと同時タイプでカタカナが入力される様にするには、 ${HOME}/.uim を適当にいじってやればよい。
拙作の 「uim-Anthy のキーカスタマイズで大文字と小文字を別のキーとみなすパッチ（Canna+kinput2風）」 参照。
普通は使わないと思うので、上記ページの設定サンプルでは、 コメントアウトしてある。 for KATAKANA (type 2) と for KATAKANA (type 3) の [] のあいだ。
さて、アイディア時点での話はともかくも、 現実的な需要は有るのだろうか。 需要が無いのにやってもなぁ。

↑*3 Firefox と gimp の ソースパッケージからのアップデート終わんない〜、 とか何とかやっている待ち時間にいじっていたら、もうできた……。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」 の patch13Bptn21。 番号は patch13C か patch13-2 か patch14 にすべきかもしれないけれど、 バージョンの仕分け方を考えるのが面倒になった。 patch12/13B に対する付加機能だからいいか。
vagus氏の構想だと、 「区切りを指定した所では必ず区切り、指定しなかった所は自動判定」 だそうですが、 面倒なのと、 「絶対区切らない指定は、どうしたら良いだろう」と言うのが有って、 そこまでは至らず。 「区切りを指定した所では必ず区切り、指定しなかった所は絶対区切らない」 になっています。
あと、（辞書や変換エンジンのクセや傾向を考えて） 「文節区切り位置を間違えそうな所で、あらかじめ指定する」 と言う芸当ができるのは、vagus氏だけではないかと思います……。 「ここではきものをぬいでください」の様に、 どこが区切りなのか書いた本人にしか判らない物はともかくも……。

↑ とか何とか書いていたら、 「区切りを指定した所では必ず区切り、指定しなかった所は自動判定」 の実装方法も思い付いてしまった……。

↑ 「区切りを指定した所では必ず区切り、指定しなかった所は自動判定」、 取り敢えず試す事が出来そうな物はできあがり。
MANUALLATTICE_MODE true 指定すると 「区切りを指定した所では必ず区切り、指定しなかった所は絶対区切らない」。
VITERBI_MODE true か MAXLEN_MODE true 指定して、 LATTICE_HINTING_BY_KATAKANA true 指定すると、 「区切りを指定した所では必ず区切り、指定しなかった所は自動判定」。
あと、 日曜の夜にアップロードした版(Sat,18 Apr,2009版)はバグ （文節区切りの訂正操作が、できなかったり、 無理にやろうとするとメモリ破壊かメモリリークを起こす） があるので更新されたし。 月曜中に修正版(Sun,19 Apr,2009版)を再アップロードする予定。 アップロードした。

↑ うーん、上記の２方法を実装した感触だと、 カタカナ平仮名での区分けだけでなく、 文節区切り用文字を挿入する方法でも実装できるなぁ。
「bunnsetsu;kugiri;itiwo;syudou;nyuuryokusuru;mo-dowo;tuika」 とタイプすると、 「ぶんせつ;くぎり;いちを;しゅどう;にゅうりょくする;もーどを;ついか」 と表示されて、 「|ぶんせつ|くぎり|いちを|しゅどう|にゅうりょくする|もーどを|ついか|」 と区切られる方式。 この方が人間には見やすいし、 SKK方式のシフトキー連打で挫折した人でも使えるし。

↑ それから。 人間が文節区切りを全て漏れなく入力するのは大変、と考えると、 「区切りを指定した所では必ず区切り、指定しなかった所は自動判定」 の方が良いかもしれない。

↑*3 anthy-9100h + alt-cannadic-090308 + alt-depgraph-090308。
「|終わんね|」（おわんね）、
「|終わらね|」（おわらね）、
がでない……のだけれども、 ここまで極端な音便？方言？変則？は出なくて当然かも。
「|終わらない|」（おわらない）、
「|終わらねえ|」（おわらねえ）、
「|終わらねぇ|」（おわらねぇ）、
「|終わんない|」（おわんない）、
「|終わんねえ|」（おわんねえ）、
「|終わんねぇ|」（おわんねぇ）、
は出る。

↑*? ここ数日の、 Anthy で文節区切りを明示的に指定しながら入力する方法の続き。 「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
文節区切り用文字をタイプしながら入力する方法でも実装できた。 詳細は 「patch12/patch13/patch13B パターン２１：」 を参照。

uim-anthy にて入力する際に、 短い文節を入力しては確定し、短く入力しては確定し、 の方法で入力する場合に、 変換結果を良くする方法。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」

先に結論：
実際に実装したとしても、そんなに劇的な効果は無いと思う。
実装するとすれば、 直前に入力された内容を保持しておき、 直前の内容と今回入力された内容を組み合わせて、 複合語が適用できるなら適用して高得点にする、 OCHAIRE学習が適用できるならば適用して高得点にする、 その辺りになると思う。
その際に、誤適用／誤学習を防ぐには、 フロントエンド（uim,scim,iiimf,imなど）の改造が必要。

適切に適用できる状況がどれ位の頻度で有るのか微妙。 手元の計測結果だと、１〜３割ぐらいかもしれない、 有効か無駄か微妙なライン。

Thu,23 Apr,2009 追記：
コーパスを有効にしている場合、 直前の文節によって、 現在の文節の各候補のスコアリングに調整が入っているのを忘れていた。
なので、下記に書いた思考過程には、スコアリング調整のぶんが抜けている。 Thu,23 Apr,2009に続く。

Mon,27 Apr,2009 追記：
何だかんだ言っておきながら、結局実装。 Mon,27 Apr,2009に続く。

適切に適用できる状況が発生する頻度を推定する為の実測結果は、 「Anthy 改造パッチの詳細解説と覚え書きと落書きとグチ - 継続使用の試験結果とかベンチマーク結果とか - Tue,21 Apr 2009」 を参照。

思考過程：

万事想定通りに情報が得られる場合：
直前の単語の品詞と付属語（のハッシュ）を見て ビタビアルゴリズムの確率を修正したとしても、 文節区切りの判定には用いられるが、 各文節毎の候補の並び順には反映されない。 ビタビの文節区切りの判定に用いたとしても、 文節を細切れに入力するクセのある人に於いて、 文節区切りの判定に役だっても……。
前方ｎ文節最長一致は、そもそも直前の単語を見ていないし、 各文節毎の候補の並び順には影響を与えない。
よって、文節区切りには、あまり役に立たないかもしれない。
各文節毎の候補の並び順に於いては。 「（前に入力した単語につながる）複合語なので高得点」、 「（前に入力した単語につながる）学習が適用されて高得点」、 の点では、役に立つ。 でも、その様な状況がどれ位の頻度なのかと言う問題がある。

そもそも、想定通りの情報が得られるとは限らない：
現状では、 無変換で確定した場合は、 フロントエンドから変換エンジンには情報が来ない。 行編集やカーソル移動などを行った場合も、情報が来ない。
なので、直前の変換確定結果が、 今回の変換内容の直前の内容か否かが判らない。
「今回の変換内容の直前の内容か否かが判らない。」 と言う内容を 「今回」「の」「変換」「内容の」「直前」「の」「内容か」「否か」「が」「判らない」「。」 と分けて入力されたと想定すると、変換エンジン側では 「今回」「変換」「内容の」「直前」「内容か」「否か」「判らない」 を得る事になる。
複合語辞書に「変換_内容」が登録されていると仮定すると、 「変換」「内容の」は、 直前の変換内容を知る事で複合語の適用ができる。
「今回」「変換」は、 直前の変換内容を知っても何の情報も得られない （ビタビの遷移確率の計算に利用すると、むしろ害になる。 「今回」と「今回は」では品詞とか付属語ハッシュ値とかが違うので）。
「否か」「判らない」は、 直前の変換内容を知る事で有効な情報が得られるけれど、 「今回」「変換」の時と区別を付ける方法が無い。
「今回」「変換」、 「内容」「直前」、 「直前」「内容」、 「内容」「否」、 「否」「判」、 においては、 連続する文節の自立語部分を抽出した学習が適用できる。 但し、学習データの利用効率が低い。 あと、 行編集やカーソル移動などを行った事を知る事ができないと、 誤適用してしまう。
行編集やカーソル移動などを行った事を知る事ができないので、 OCHAIRE学習とか連続する文節の自立語部分を抽出した学習などにおいて、 行編集やカーソル移動をされると、誤学習してしまう。 誤学習を防ぐ為に学習しない様にすると、 文節を細切れに入力する人の場合に学習できなくなる訳で、 学習できないとなると学習の適用も出来なくなる訳で、 学習の適用ができないならば直前の内容を知っても無駄な訳で。
uim等のフロントエンド側を、 その手の情報を通知してくる様に改造する？。 誰が改造するの？。 原作版 Anthy との互換性確保はどうする？。

情報を通知する様にフロントエンドを改造したとして：
入力する文の内容を推敲しながら、 「直前の内容か否かが判らない。」、カーソル移動、 「変換内容の」、カーソル移動、「今回の」、 の順で入力されると、効果が無い （毎回リセット情報が通知されてくるだけ）。
平仮名／英数記号だけの入力があった場合、 自立語なのか、付属語なのか、自立語＋付属語なのか、 複数の文節で平仮名／英数記号が続いているのか、 わからない。 なので、 「連続する文節の自立語部分を抽出した学習」や、 「連続する文節の付属語部分を抽出した学習」などを、 学習したり適用したりする事は、やっぱりできない。 OCHAIRE学習においても、 文節区切りが有るのか無いのか、 自立語と付属語の境目が有るのか無いのか、 あるいは区切れは全然関係無いのか、 などが、判断できないので、誤学習や誤適用が増えるかもしれない。

プログラムの構造上の話：
変換コンテキストは窓毎に保有しているっぽいので、 直前に入力された内容は変換コンテキストに保存しておく事ができそう。 ターミナルソフト側で IM の通信切断を行うまでは、 コンテキストは保持され続けているし。

以下、uim-anthy の処理の流れ。

起動（uim-xim 起動）：
uim <-> XIM bridge. Supporting multiple locales.
Using full-synchronous XIM event flow
Anthy: TRACE: anthy_init();
Anthy: TRACE: anthy_get_version_string();
Anthy: TRACE: anthy_create_context();
ここで学習結果を読み込むので（たぶん）、ちょっと時間がかかる。
Anthy: TRACE: anthy_release_context();
ここで読み込んだ学習結果を破棄している。
Supported conversion engines:
  direct (*)
  anthy (ja)
XMODIFIERS=@im=uim registered, selecting anthy (ja) as default conversion engine

接続（kterm では Open Input Method、mlterm では mlterm 起動）：
Anthy: TRACE: anthy_get_version_string();
Anthy: TRACE: anthy_create_context();
ここで再び学習結果を読み込むので（たぶん）、ちょっと時間がかかる。

IM を On（API 呼び出しは何も無し）：

入力：
（API 呼び出しは何も無し）

変換：
Anthy: TRACE: anthy_set_string();
Anthy: TRACE: anthy_get_stat();
Anthy: TRACE: anthy_get_segment();
Anthy: TRACE: anthy_get_segment();

次候補：
Anthy: TRACE: anthy_get_stat();
Anthy: TRACE: anthy_get_segment_stat();
Anthy: TRACE: anthy_get_segment();
Anthy: TRACE: anthy_get_segment();

決定：
Anthy: TRACE: anthy_get_segment();
Anthy: TRACE: anthy_get_segment();
Anthy: TRACE: anthy_commit_segment();

入力：
（API 呼び出しは何も無し）

決定：
（API 呼び出しは何も無し）
ここで平仮名／英数記号だけからなる内容を入力されていると、
変換エンジンはその事を知る事ができない。
辞書に登録されていない単語を、別の読み方で分解して入力した場合も、
同様に知る事ができない（そういう内容の文章が有ると誤判定してしまう）。

入力：
（API 呼び出しは何も無し）
ここで、
継続して変換内容を入力しているのか、
行編集やカーソル移動などの継続入力ではない作業を行ったのか、
その辺りを uim から Anthy に通知する API が無いので、
変換エンジンは、継続入力なのか、新規入力なのか、知る事ができない。

変換：
Anthy: TRACE: anthy_set_string();
Anthy: TRACE: anthy_get_stat();
Anthy: TRACE: anthy_get_segment();
Anthy: TRACE: anthy_get_segment();

決定：
Anthy: TRACE: anthy_get_segment();
Anthy: TRACE: anthy_get_segment();
Anthy: TRACE: anthy_commit_segment();

入力：
（API 呼び出しは何も無し）

カタカナ／平仮名変換して決定（uim-1.5.5以降）：
Anthy: TRACE: anthy_set_string();
Anthy: TRACE: anthy_get_stat();
Anthy: TRACE: anthy_commit_segment();
この辺りのカタカナ語／平仮名語の強制学習機構を応用して、
無変換の強制学習機構を追加してやれば、
無変換で入力確定された場合でも、変換エンジンがその事を知る事が出来る。

IM を Off（API 呼び出しは何も無し）：

切断（kterm では Close Input Method、mlterm では mlterm 終了）：
Anthy: TRACE: anthy_release_context();


備考：
継続した入力でない場合は一旦切断する（anthy_release_context）、と言うのは駄目。
初期化処理や、学習結果の再読み込み（たぶん）が入ってしまうので、遅くなる。
拙作パッチで学習量を増やしていた場合は尚更遅い。

備考：
継続ではない入力だった場合、空文字列で anthy_set_string(), anthy_commit_segment() で通知すれば、
API を追加する事無く、原作版 Anthy でも通知対応版 Anthy でも、どちらでも動作する様に出来るかも。
但し、原作版 Anthy にて、空文字列が入力された時に誤動作を起こさない事を確認する必要が有る。

↑ anthy.scm を適当にいじっていたら、 無変換で確定した場合でも通知する様に出来た。
IM を off にした場合に、 リセット通知用の空文字列を通知する様に試行錯誤してみたが、 こちらは通知出来る様にできなかった。 トリガをかけるべき場所が見つからない。
原作版 Anthy の場合、無変換で確定した場合に通知すると、 入力した内容を何でもかんでも学習する様になった。 有害とは言い切れないが、無害とも言い切れず。
あと、先日書いた通りの理由で、 学習データの利用効率も低めだし 手間がかかる割に効果が高くないと思うので、 あんまり乗り気にならない。 さて、どうしたものか。

Mon,27 Apr,2009 追記：
↑ 何だかんだ言っておきながら、結局実装。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
Mon,27 Apr,2009に続く。

「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」、 の patch13Bptn21 更新。
フロントエンドの↑改造を行った時に、 無変換で確定の時は学習しない、 平仮名／カタカナ変換の時は ENABLE_AUTOLEARN で学習の有無を選択可能。

「;」(JIS X 0201) を区切り文字にした時の 「；」(JIS X 0208) の入力方法。
uim-anthy ならば、↓ を ${HOME}/.uim に追加すれば、 「;」(ASCII) とタイプした時は区切り文字となり、 「;;」(ASCII*2) とタイプすれば「；」(JIS X 0208) の入力となる。 「;;」(ASCII*2) とタイプしてカタカナ変換すると「;」(ASCII) が出る。 あるいは、 「；」(JIS X 0208) を入力して変換すると候補の中に「;」(ASCII) がある。
「;a」とかを追加しておかないと、 「;あ」が入力できなくなった。謎。

;;
(require "japanese.scm")
(define ja-rk-rule
  (append '(
;; for anthy patch13Bptn21 [
        (((";" ";"). ())("；" ";" ";"))
        (((";").     ())(";" ";" ";"))
        (((";" "a"). ())((";" ";" ";") ("あ" "ア" "ｱ")))
        (((";" "i"). ())((";" ";" ";") ("い" "イ" "ｲ")))
        (((";" "u"). ())((";" ";" ";") ("う" "ウ" "ｳ")))
        (((";" "e"). ())((";" ";" ";") ("え" "エ" "ｴ")))
        (((";" "o"). ())((";" ";" ";") ("お" "オ" "ｵ")))
        (((";" "A"). ())((";" ";" ";") ("ア" "あ" "ｱ")))
        (((";" "I"). ())((";" ";" ";") ("イ" "い" "ｲ")))
        (((";" "U"). ())((";" ";" ";") ("ウ" "う" "ｳ")))
        (((";" "E"). ())((";" ";" ";") ("エ" "え" "ｴ")))
        (((";" "O"). ())((";" ";" ";") ("オ" "お" "ｵ")))
;;]

        )
          ja-rk-rule))
;;

↑ uim 以外は使っていないので、 各自宜しくやって下さい。

文節区切りの入力。
句読点を多めに入れる感覚で「;」を打っていけば、 多分、読みを入力するのと同時にタイプしていても、 それほど気にならない様な気がする。
vagus氏の構想に書かれていた通り、 全部の区切りを入力するのは人間の負担が大き過ぎた。 指定が無い部分を自動補間させないと、やってられなかった。
「va vi vu ve vo」は「う゛ぁ う゛ぃ う゛ う゛ぇ う゛ぉ」と 平仮名で入力されると思う。 それから、 例えば「じゃ」が文節区切りになる場合は、 「ジゃ」と入力する必要が有る （拙作 uim.kana.conf では、 「;zya」と入力すると「ジゃ」、 「Zya」と入力すると「ジゃ」、 「ZYA」と入力すると「ジャ」、 となる様に設定してある）。
あと「;」は、微妙に場所が悪い。 shiftキーよりは楽だけれども、やっぱり押しやすくはない。 vagus氏の構想通り、スペースバー／スペースキーが押しやすそうだが、 スペースを文節区切り指定と変換開始で共用するには フロントエンドのソフトウェアの改造が必要なので、 誰かが改造版を作ってくれるまでは使えない。 キーバインドをいじって 「無変換」キーか「変換」キーを割り当てるならば、 改造は不要だが、これもやっぱり微妙に押しにくい。 そんな貴方に、 親指シフトキーボード（の、親指変換キー）？。

↑ Fri,24 Apr,2009 追記：
「丘の道を登り - 2009年04月23日 - お返事色々」 での御指摘通り、 「va vi vu ve vo」とタイプした時に、どんな風に入力されるかは、 フロントエンドに使用するソフトウェアや環境設定に依って、 全然違います。
「va vi vu ve vo」が「う゛ぁ う゛ぃ う゛ う゛ぇ う゛ぉ」になるのは、 uim-anthy の標準設定で何も変更しなかった場合です。
ですので、各利用者側で、よしなに宜しくやって下さい。

「；」のコード。
区点が 01-08 で JIS が 2128。 ……どうでもいいな。

蛇足：
「前候補／変換」キーと「カタカナ／ひらがな」キーは使った事が無い。 指が届かないのだ。
「~」を入力する際は、「Shift + 0」(OADG109) を使っている。 「Shift + ^」(OADG109A) は指が届かないのだ。

「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」 の patch13Bptn21 更新。

「vagus氏 - 丘の道を登り - 2009年04月23日 - むう」 の件を修正、 文節区切り文字だけ入力した場合はそのままスルーします。
uim-anthy が落ちるのは、uim の方が落ちている気がする。 anthy-agent で試した時は、 anthy のエンジン側ではなく、anthy-agent側で落ちた。

uim-anthy にて入力する際に、 短い文節を入力しては確定し、短く入力しては確定し、 の方法で入力する場合に、 変換結果を良くする方法の話、 「Mon,20 Apr,2009 〜 Tue,21 Apr,2009」 の訂正。
コーパスを有効にしている場合、 直前の文節内容に依って、 現在の文節の各候補のスコアリングに調整が入っているのを忘れていた。
ソースで言うと、 src-ordering/infosort.c で mw->struct_score に設定し、 src-ordering/candsort.c でそれを参照している辺り。
「直前の文節の品詞と、現在の文節の品詞の、組み合わせ？」、 「現在の文節の付属語のハッシュ値」、 「現在の文節の付属語の品詞？」、 「現在の文節の自立語のシステム辞書上の頻度値が、大きい方の区分か小さい方の区分か（２択）」、 「現在の文節の付属語が、付属語グラフで weak 指定が有るか無いか（２択）」、 あと現在の文節に関してこまごまとしたのが幾つか、 のパラメータにて分類し、 同じ分類となる物がコーパスに有るかどうかを検索し、 該当があれば 「現在の文節の自立語のシステム辞書上の頻度値」に補正が行われる （コーパス情報に該当が有る場合、頻度値が最大10倍に補正される）。
なので、直前の文節の内容が判る場合、 複合語や OCHAIRE学習に該当が無い場合でも、 コーパスに該当情報があれば現在の候補一覧に影響が有る。
完全一致した時のみ利用される複合語や OCHAIRE学習よりは、 分類別での仕分けのコーパスの方が利用頻度（該当率）が高くなるとは思う。
毎度お馴染みの？、 コーパスが各利用者にみあった適切な文例集になっているか否かとか、 コーパスの分量が足りているのか否かなどは、 単刀直入に言うと、知らん。

↑ 直前の内容が無変換での確定の場合だと、 品詞が判らないからコーパスは利用できない。
逆に、複合語や OCHAIRE学習は、 読みと変換結果（読みと同じ）が判明しているので利用できる。

Anthy で文節区切り文字。

• uim-anthy にて、 「スペース」をタイプした時は区切り指定、 「CTRL + スペース」をタイプした時は変換開始。
• フロントエンド問わず、 「無変換」キーや「前候補」キーを区切り指定にする。

を追記。 「patch12/patch13/patch13B パターン２１：」。

「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」、 patch13Bptn22 追加。
直前に入力もしくは変換された内容を、 変換のスコアリングの参考情報として保持する機能を追加。
入力／変換する際に、 短い文節を入力しては確定し、短く入力しては確定し、 の方法で入力する場合に、 変換結果が良くなるかもしれないし、 変わらないかもしれないし、 悪くなるかもしれない。

この機能、構想自体は、 パッチ製作を始めたごく初期から有ったものだけれども。 実装するか否か迷い迷ってようやく実装。
効果の程は、今の所、体感できる程の明確な違いは見つからず。 むしろ、 学習させすぎで遅くなったり誤適用したりが目立ち始めているし。

↑ 動作確認中に、 想定していた処理が行われない場合が有るのを見つけた。
追究してみたら。 LATTICE_AUTOEXPAND_DEPS の実装を、 Anthy の構造に合わせて手抜きしていた部分がもろに出ているだけだった。 そう言えばこの件は、 以前から何度もひっかかっては棚上げしている部分だった。
いい加減、再実装してみるか……。
と言う訳で、patch13Bptn23 を予告。

「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」、 patch13Bptn22 修正。
patch13Bptn23 の内容が混ざってしまっていたのと、 ドキュメントの改訂を忘れていた。

「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」、 patch13Bptn23 追加。
LATTICE_AUTOEXPAND_DEPS を再実装し、想定通り機能する様にした。
これで問題無いかどうか、実地テスト中。

↑ 注意：
「|文節の|区切り方|」（|ぶんせつの|くぎりかた|）
と言う学習が有る時に、
「ぶんせつのくぎりかたとかのはなしはどうなるのだろう」
を変換すると、 前方ｎ文節最長一致モードでは
「|文節の|区切り方とかのはな|しは|どうなるのだろう|」
となってしまうのは、 前方ｎ文節最長一致のアルゴリズムと LATTICE_AUTOEXPAND_DEPS を組み合わせた時の 想定通りの動作なので、バグでは無い。

前方ｎ文節最長一致のアルゴリズムは、 文章全体の文節数と各文節の長さの情報を用いて区切り位置を判定するので、 各文節の内容や組み合わせを用いて判断する事は出来ない（しない）。
そう言う事をする様にしたのがビタビなどの確率的あるいは統計的手法なのだし。

ビタビモードでは
「|文節の|区切り方とかの|話しは|どうなるのだろう|」
になると思う。

uim-anthy。
なんとなく anthy.scm を適当に眺めたら、 IM を on にした時の処理部分がみつかった。 数分眺めていただけで見つかるなんて、 １年以上前と半年前に各々小１時間いじって失敗したのは何だったのだろう……。
「patch12/patch13/patch13B パターン２２：」、 anthy.scm と anthy-utf8.scm を、 IM を on にした時には継続入力内容をリセットする物に更新。
これで、 非 GUI版のエディタ使いならば、問題はほぼ全て解決される筈。 CUI版の vim使いで vim連動モードにしている人とか……。 もっとも、GNOME とか KDE とか使っている人だと、 何も解決されていないのだけれど。
そして私は vim連動モードで CUI版の vimを使っている人なので、 これ以上、 uim-anthy用 anthy.scm の追究をする気は無かったりすると言う……。
追記：明日に続く。

uim-anthy。
ふと anthy.scm を眺めたら、 カーソル移動やバックスペースを行った時の処理部分も見つかった。 数十秒眺めていただけで見つかるなんて、 １年以上前と半年前に各々小１時間いじって失敗したのは何だったのだろう……。 まぁ、そう言う事ってわりとあるけれど。
「patch12/patch13/patch13B パターン２２：」、 uim-anthy用設定ファイルのサンプルの、たぶん完成版。

↑ 問題は、無変換やカタカナ／ひらがな変換で確定した場合でも、 漢字変換を行なったのと同等の遅延が入ってしまう事。
処理構造上、一旦、漢字変換を行なって、 その中から無変換／カタカナ変換／ひらがな変換と 等価の変換結果となる候補を検索して、 その候補を選択して確定処理を行っているから、 当然、遅延が入ってしまうのだけれど。
はっきり体感できる程の遅延が増えている。 ううむ。

↑ 結局、専用 API 追加で遅延を無くしてみた。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」、 patch13Bptn22, patch13Bptn23 更新。
「patch12/patch13/patch13B パターン２２：」、 uim-anthy用設定ファイルのサンプルを更新。

↑ 副作用として、内海 氏の強い要望が有ったらしい？、 カタカナ／ひらがな変換した結果を自動学習する機能が、 無効になる。
有効にしたければ、 anthy.scm と anthy-utf8.scm の、 anthy-commit-transposing-text と anthy-commit-unconverted-transposing-text と anthy-reset-commit-transposing-text と anthy-utf8-commit-transposing-text と anthy-utf8-commit-unconverted-transposing-text と anthy-utf8-reset-commit-transposing-text に、 (define (expand-segment) 以下略) を追加して (anthy-lib-commit-segment ac-id -1 ほげほげ) を (expand-segment) (anthy-lib-commit-segment ac-id 0 ほげほげ) にする。 その代わり、遅延が入る。
そんな事するのが面倒ならば、 普通に漢字変換して、その中から平仮名／カタカナの候補を選べば良し。

↑*2 余計な学習や間違った学習が行われなくなったので、 昨日よりは良い感じ。

「vagus氏 - 丘の道を登り - 2009年04月29日 - depgraph: 「文末」属性」の、 付属語グラフに文末属性を追加するアイディア。 コメントに書こう（書くならコメントに書くべき）と思ったけれども、 長いのと書き終わらないのでヤメ。
Tue,05 May,2009 追記：
「丘の道を登り - 2009年04月30日 - depgraph: 「文末」属性 - 【追記】5/2」
付属語グラフに文末属性を追加。

→ patch13Bptn23 にて導入。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」

「Sz@」、「Sz.@」、「Sz:@」にて、文末属性が付加される。
ある文節に文末属性が付いており、 その文節の次の文字が平仮名／カタカナの場合、
・学習にて、そこで文節を区切る様に指定されている
。 ・変換時に、手動でそこで文節を区切る様に指定した。
の場合を除き、そこで文節を区切らなくなります。

例）
「|見んな|」（|みんな|）に文末属性が付いている場合。
「みんなといった」を変換する時に、 「|みんな|といった|」の区切り方だと、 文末属性が付いている文節「|見んな|」の次の文字が 「と」であり平仮名なので、 「|見んな|」と言う文節は使われなくなります。


試しに、 「文末属性の文節の直後に平仮名／カタカナが来たら、 1/100 に確率減少（ビタビ区切り）／減点（ｎ区切り） ／減点（文節の候補の並び順）」で、 実装してみたところ。
「|夢か|萎えてくれよ|」（|ゆめか|なえてくれよ|）。
なかなか思い通りにはいかない様でして……。
あるいは、確率減少／得点減少ではなくて、 完全使用禁止にした方が良いだろうか （その場合でも「|夢か|萎えてくれよ|」の場合は変わらないと思われる）。
なお、 文末属性の文節の次の文節が、単漢字の文節か否か、で 判定するのは無理です。 「次の文節」の後ろ側の文節区切りの位置によって、 単漢字になったり名詞／動詞／（以下略）になったり変化するので、 処理できません。
「ぁぃぅぇぉゃゅょ」辺りのどれかが、 平仮名ではない、と判定されている気がしますが、 もしそうなら、原作版 Anthy の仕様です。
「|見んな|と言った|」（|みんな|といった|）は不適切な区切りで、 「|見んなと|言った|」（|みんなと|いった|）が適切な区切りだろうか。 「見んな」（みんな）に文末属性を付けると、そうなってしまうけれども。
あと、文末属性に対応すると、
付属語グラフを文末属性対応に書き換える必要が有る、
原作版そのままの Anthy では使用できなくなる （要、文末属性対応パッチ）、
コーパスデータベースの更新 update_params が必須になる （既に alt-cannadic で、そうなってはいますが）、
問題と言うか手間と言うかがあります。

↑ 「anthy-9100h + patch13Bptn23.2009429 + alt-depgraph-090408 に、さらに追加するパッチ anthy-9100h.patch13Bptn23.2009429.alt-depgraph-090408.EndOfSentencePatch.2009430.bz2」。 付属語グラフの、「Sz@」、「Sz.@」、「Sz:@」にて、文末属性になります。
なぜ「Sz」かと言うと、 「Se」、「Sf」、「St」は、もう使われていたから。
EndOfSentencePatch.2009430版には、 変換しようとした内容と同じ内容が、学習データに有る場合、 文末属性が効かなくなるバグと言うか手抜きと言うか、 があるので注意。
Sat,02 May,2009 追記：
patch13Bptn23.2009501版にて、↑とか↓とかも修正して対応。

↑ 学習データにヒットすると文末属性が効かない件から 連想して気付いた。 原作版 Anthy でも拙作パッチ版でも、 学習データにヒットすると、コーパス処理が出鱈目になっている。
「|効かない|件から|」が学習に有った場合に 「|文末属性が|効かない|件から|連想して|」の変換をしようとすると、 「|文末属性が|効かない|」の部分と「|件から|連想して|」の部分で、 コーパスの検索に使う seg_class と dep_class と dep_hash などが 間違った値になっている。
結果、 「|文末属性が|効かない|」の部分と「|件から|連想して|」の部分で、 コーパス由来の確率調整が出鱈目になったり、 例えば「|件から|」が文末属性（現実の運用ではそんな事は無いけれど） だったりしても無視される。
「|効かない|件から|」の部分も間違った値にはなるが、 コーパスよりも学習が優先されるので、影響は無い。

「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」、 patch13Bptn23.2009501 にて、文末属性対応。
付属語グラフの、「Sz@」、「Sz.@」、「Sz:@」にて、文末属性になります。
付属語グラフで文末属性を使わなければ、特に変化は無し。
手動指定時／学習で区切ると指定された場合を除き、 文末属性の文節の直後に平仮名／カタカナが来たら、 文末属性の文節が使用禁止になる （文末属性が付いていない文節を探して使用する）。
学習データにヒットした場合でも、一応、文末属性やコーパスが効く筈です。 一応と言うのは、Anthy の構造上、完治できないから。

↑ 文末属性を試してみたところ。
「|こんな|」と「|見んな|」が、 付属語グラフの同じ地点で終点になっている様な気がします。 「|見んな|」を文末属性にした所、 「|こんな|」も文末属性になってしまいました。
うーむ。 見間違いだとか作業ミスとかだと問題が出なくていいのですが。
Thu,07 May,2009 追記：
「丘の道を登り - 2009年04月30日 - depgraph: 「文末」属性 - 【追記】5/2」、 「|来んな|」（|こんな|）の平仮名表記なので問題無いらしい。

「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」、 patch13Bptn23.2009502 に更新。
ENABLE_ERROR_RECORD を使用した際に、 ENABLE_OCHAIRE2_WITHOUT_INDEP, ENABLE_OCHAIRE2_WITHOUT_INDEP_WITHOUT_DEP, ENABLE_OCHAIRE3_WITHOUT_INDEP, ENABLE_OCHAIRE3_WITHOUT_INDEP_WITHOUT_DEP にて学習された内容に対するエラー判定が間違っており、 エラーではない場合でもエラー判定する事が有ったので修正。

「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」、 patch13Bptn23.2009503 に更新。
patch13Bptn23.2009502 での修正に、修正漏れと修正間違いがあった。

「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」、 patch13Bptn23.2009504 に更新。
ENABLE_ERROR_RECORD と --enable-debug の調整。
……何かドツボにハマっている気がする。

Anthy の付属語グラフを全探索するプログラム depgraphdump。
Anthy の付属語で、
「これは一体どういう遷移でここにたどり着いたのだろう （「見んな」に文末属性を付けたら、 「こんな」にも文末属性が付いてしまった気がする）」
と疑問に思う候補とか、
「weak を調整した方が良いかも （これは、以前、nosuke氏のサイトの nosuke氏や vagus氏の コメントを読みながらいじっていた頃の話）」
と思う候補とか、 が、たまにある。たまに。
Anthy 本体の付属語遷移の表示は、 目的の遷移を探すのにはどうにも使いにくい （ノードの名称が表示されないので、 元ファイルとの突き合わせが出来ない）。
Nanthy の 謎(nazodane) 氏のサイトにある付属語グラフの探索ソフトは、 ランダム表示なので、目的の遷移を探すのには使えない。 ノードの名称も表示されないし。 ソースも D言語で書かれているので、 利用させて貰い、ちょっと気軽に改変、と言う事はできない。
なので、自前で、 付属語グラフを全ダンプするプログラムを作ってみた……のだが。
内容的にはプログラミング初心者の練習用に最適な課題っぽい気がするなぁ、 と思いつつ、 ３時間も有れば骨格部分は出来上がるかな、と思っていたら。
……とんでもなかった。 枠組みだけで累計２時間の、骨格部分だけで累計９時間かかった。 衰えたか？。
まぁ、 STL の map とか multimap とか言うのを、 使い方を調べながら初めて使ってみた、 のは確かなのだけれども。 途中で付属語グラフの書式を間違えていた事に気付いて、 作り直す羽目になるし。
まだ表示部分が未完成なのだけれども、骨格の探索部分は出来上がったので、 探索部分だけで、動かしてみたところ。 全探索させたら、 ちゃんとループの回避を行っているにも関わらず、 探索結果の表示が 500MB 越えても終わらない……。

↑ 取り敢えず４文字以上で探索打ち切り、の条件で探索してみたら、 240万パターン近く出てきた。 想像していたよりも２〜３桁くらい多い。
探索条件をもっと絞れる様にしないと駄目だね、こりゃ。

↑ でも、 付属語の学習を見ると、1300 ぐらいで頭打ちになり始めている感じで、 2000 は行きそうに無いし、 5000 は行かない様な気がする（気がするだけ）。 それを考えると、よく使う付属語って、結構偏っているのね。

↑ Sat,09 May,2009に続く。

Anthy 拙作パッチ。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」

「nosuke(のすけ)氏 - 日記みたいな何か - 2009年 5月 2日 (土) - Anthy」
alt-depgraph-090408 と組み合わせた前方ｎ文節最長一致モードにて、 「さたーん」を「|沙汰|ー|ん|」（|さた|ー|ん|）と変換確定して 学習をした後に、 「|さたー|ん|」と文節を区切って変換候補を出そうとすると クラッシュする。

→ patch13Bptn23 にて、それと気付かずに治していた。

→ 原因
CAND_HISTORY 学習に「ん」があり、 かつ LATTICE_AUTOEXPAND_DEPS が有効になっているので、 「ん」の付属語を削除して、 別の付属語を付けた文節が生成可能かどうか探そうとする。
ここで、付属語グラフより、 「|ん|」が、自立語の文字数０、付属語の文字数１、 となっているので、 「||」（文字数０の文字列）を基準にして探し始めるのだけれども。
変換候補の文字数別一覧を使って、
for (
（無符号整数：探索中の文字数）=（その文節の先頭から文末までのよみがなの長さ）;
（無符号整数：自立語の文字数） <= （無符号整数：探索中の文字数）;
--（無符号整数：探索中の文字数）
)
とかやっていて、さようなら。

→ 対処
patch13Bptn23 にて、 LATTICE_AUTOEXPAND_DEPS の実装を丸ごと書き直した際に、 変換候補の文字数別一覧を使わない方法にした。

「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」、 patch13Bptn23.2009506 に更新。
AUTHORS.patch の内容が間違っていたので修正。
いかん、ジンクス発動しまくり。

Anthy の付属語グラフを全探索するプログラム depgraphdump。
取り敢えず、 探索を開始するノード名、 付属語の先頭部分の文字列、 を指定できる様にしてみた。
前方検索（左→右の方向での探索）は、こんな感じで完成だと思う。
いい加減、手段が目的化してきた……。
「depgraphdump.cc(39KiB) 後方探索が未実装」。

↑ 探索範囲７文字、途中表示無、未使用ノードの検出のみ、 の条件で探索してみた所、 「する××形」の部分の探索だけで10分弱かかって、 全部完了するまでに２時間ちょっとかかった。
結果。
「@_サ変連用形(共通)」から遷移しようとしている「@_補動「やる」(複合・可動)」
「@_上下一段連用形(共通)」から遷移しようとしている「@_補動「やる」(複合・可動)」
が、無い。   と思ったら、コメントアウトしてあった。
それから、
@「たら」終助
@「たら」副助
@「ちゃ」接助(引用)
@「ほど」副助(準体)
@補動「ある」終止形I
が、未使用と出たが、探索範囲を長くすると使うのかもしれない。   でもこれ以上探索範囲を長くするといつまで経っても終わらなくなるので、 後方探索（右→左の方向での探索）を実装しないと、チェックできない。

↑*2 「いいのね」で始まる物だけで検索してみた所。
Loop: する仮定形「すりゃ」|いいのねーってだけならばですからみたいじゃそうじゃしでにらしいかからみたいだのじゃないながらのようじゃとするべからざるままであるまいなんぞとさえもなさそ うじゃとかのないくらいまでなんてものへなんかからとのなどは HnS Cg :0.3 @する仮定形「すりゃ」 "" @_補形「いい」 "" Cs@補形「いい」終止形 "いい" @「の」終助 "の" @「ね」終助 "ね" @(詠嘆音引き)終助 "ー" @_引用(共通) "" @「って」格助(引用) "って" @「だけ」副助 "だけ" @_助動「だ」 "" @助動「だ」仮定形 "なら" @「ば」接助 "ば" @_助動「です」 "" @助動「です」終止形 "です" @「から」接助 "から" @_助動「みたいだ」 "" @助動「みたいだ」終止形 "みたいじゃ" @_助動「そうだ」(伝聞) "" @助動「そうだ」(伝聞)終止形 "そうじゃ" @「し」接助 "し" @「て」接助(濁音便) "で" @_「て/で」接助後(助詞) "" .@「に」格助 "に" @_助動「らしい」 "" @助動「らしい」終止形 "らしい" @「か」副助 "か" @「から」格助 "から" @_助動「みたいだ」 "みたい" @助動「みたいだ」語幹後 "" @「だの」副助 "だの" @「じゃ」格助 "じゃ" @_補形「ない」 "" Cs@補形「ない」終止形 "ない" @「ながら」接助 "ながら" @「の」格助(連体) "の" @_助動「ようだ」 "" @助動「ようだ」終止形 "ようじゃ" @「と」格助(用言後) "と" @_補動「する」 "" Cs@補動「する」終止形SR "する" @_助動「べし」 "" @助動「べし」未然形 "べから" @_助動「ず」 "" @助動「ず」連体形 "ざる" @「まま」接助 "まま" @「で」格助 "で" @_補動「ある」 "" Cs@補動「ある」終止形 "ある" @_助動「まい」 "" @助動「まい」連体形 "まい" @「なんぞ」副助 "なんぞ" @_格助詞接続(共通) "" @「と」格助 "と" @「さえ」副助 "さえ" @「も」副助 "も" .@_補形「ない」 "な" Cg@補形「ない」語幹後 "さ" @_助動「そうだ」(様態) "" @助動「そうだ」(様態)終止形 "そうじゃ" @「とか」副助 "とか" @「の」格助(主格) "の" @補形「ない」連体形 "ない" @「くらい」副助 "くらい" @「まで」副助 "まで" @「なんて」副助 "なんて" Hn@形式名詞「もの」 "もの" @「へ」格助 "へ" @「なんか」副助 "なんか" Hn@「から」格助(準体) "から" @「と」格助(並列) "と" Hn@「の」格助(準体) "の" @「など」副助 "など" @「は」副助 "は" .@_助動「だ」
みたいに長い物が大量に有った。 しかも、この例だと 「いいのねーってだけ」の後に、 「ならばですからみたいじゃそうじゃしでにらしいかからみたいだのじゃないながらのようじゃとするべからざるままであるまいなんぞとさえもなさそうじゃとかのないくらいまでなんてものへなんかからとのなどは」 が無限ループする。

↑ 本来の目的を忘れていた。
Fri,01 May,2009 → 「丘の道を登り - 2009年04月30日 - depgraph: 「文末」属性 - 【追記】5/2」、 「|来んな|」（|こんな|）の平仮名表記なので問題無いらしい。 の件。 今更だけれど、せっかくプログラムが出来上がったので、一応見てみる。
「見んな」になるのは、 「み #KS 見」＋「んな」だけで、
End: 上下一段活用動詞語幹|んな H SzC :0.0 @_上下一段語幹後 "" @上下一段未然形 "" @_上下一段未然形(共通) "" @_助動「ぬ」 "" @助動「ぬ」終止形(音便) "ん" @「な」終助 "な" Sz@
になる。
「こんな」は、
「こんな #RT*400 こんな」、
「こんな #T35*300 こんな」、
「こん #T35*200 こん」＋「な」、
「こん #ZX*10 こん」は付属語「な」が付かない、
「こ #kxo*450 こ」＋「んな」、
「こ #KY*400 こ」は付属語「んな」が付かない、
「こ #G5*300 こ」は付属語「んな」が付かない、
「こ #K5*300 こ」は付属語「んな」が付かない、
「こ #M5*300 こ」は付属語「んな」が付かない、
「こ #R5*300 こ」は付属語「んな」が付かない、
「こ #S5*300 こ」は付属語「んな」が付かない、
「こ #U5*300 こ」は付属語「んな」が付かない、
「こ #T35*201 こ」は付属語「んな」が付かない、
「こ #SX*200 こ」は付属語「んな」が付かない、
の各パターンがある。
「こんな #RT*400 こんな」は、
src-worddic/wtab.h:{"#RT",POS_ME,COS_NONE,SCOS_NONE,CC_NONE,CT_NONE,WF_INDEP /* "連体詞"*/},
……、開始ノードがみつからない。 "連体詞" だと WF_INDEP の部分が違う。
「こんな #T35*300 こんな」は、
src-worddic/wtab.h:{"#T35",POS_NOUN,COS_NONE,SCOS_T35,CC_NONE,CT_NONE,WF_INDEP /* "名詞(語幹,格助接続)"*/},
src-worddic/ptab.h:{"名詞35",POS_NOUN,COS_NONE,SCOS_T35,CC_NONE,CT_NONE,WF_INDEP},
End: 名詞35| H SeC :0.0 @_名詞35のあと "" Se@
になるので違う。
「こん #T35*200 こん」＋「な」は、
src-worddic/wtab.h:{"#T35",POS_NOUN,COS_NONE,SCOS_T35,CC_NONE,CT_NONE,WF_INDEP /* "名詞(語幹,格助接続)"*/},
src-worddic/ptab.h:{"名詞35",POS_NOUN,COS_NONE,SCOS_T35,CC_NONE,CT_NONE,WF_INDEP},
End: 名詞35|な HjStC :0.1 @_名詞35のあと "" Hj.@形動ダナ連体形 "な" St@
になるので違う。
「こ #kxo*450 こ」＋「んな」が、
src-worddic/wtab.h:{"#kxo",POS_V,COS_NONE,SCOS_NONE,CC_KV,CT_MIZEN,WF_INDEP /* "カ変動詞(こ)"*/},
src-worddic/ptab.h:{"カ変活用動詞未然形",POS_V,COS_NONE,SCOS_NONE,CC_KV,CT_MIZEN,WF_INDEP},
End: カ変活用動詞未然形|んな H SzC :0.0 @カ変未然形 "" @_助動「ぬ」 "" @助動「ぬ」終止形(音便) "ん" @「な」終助 "な" Sz@
になって、「見んな」の末端ノードと一致。

↑ 辞書から品詞を調べてヘッダファイルを検索して先頭ノード名を 調べる部分までは完全手動なので、結構面倒臭い。

そしてまた patch13Bptn23 にバグを見つけた。
ENABLE_ERROR_RECORD の記録メッセージを間違えている所が１ヶ所、 ENABLE_ERROR_RECORD や --enable-debug での判定間違いが１つ。
判定間違いの方は、 そもそも OCHAIRE学習に記録しているデータも間違えていた。
「|だと|思う|」とか「|と|言った|」の様に、 先頭に自立語が無い文節で確定した時に、 「自立語有り」と記録してしまっている。
もっともこれは、 「ほげほげ、だと思う」の様に、 文の中途の句読点の後に自立語が無い文節が来た場合、 Anthy の仕様で 「自立語有り、辞書上の該当単語不明。付属語無し。」 と言うデータしか得る事ができない事の兼ね合いもあるけれど。
仕方が無いので、仕様を変えて、 「自立語無し」の情報が得られる様にした。
……、 原作版の Anthy では、 句読点以外の記号の後に自立語の無い文節を書いた場合のみ、 「自立語無し」の情報が得られるけれども、 その時得られる情報での、 「この文節の開始位置」が間違っている気がする。 でも、修正した場合の影響範囲の予測が付かないので手が出せない。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」、 patch13Bptn23.2009509 に更新。

↑ あと、 「nosuke(のすけ)氏 - 日記みたいな何か - 2009年 5月 9日 (土) - Anthy」、 『「すぱーぎあ」が何度確定しても「す + パーギア」に』 の件も多少は一応対応（形容詞が変だ……）。

まず、「スパーギア」が辞書に載っていない。
次に、 原作版の Anthy の設計だと、 平仮名語／カタカナ語の自動学習は、 平仮名／カタカナだけの文節にした場合のみ行われるので、 「|数えようとして|スパーギアの|方を|」の様に 途中までカタカナで最後に平仮名、と言う文節で確定した場合は 自動学習が行われず、 いつまで経っても「スパーギア」を覚えてくれない。
拙作パッチの 2009509版よりも前までも同様。

なので、何度確定しても「スパーギア」が出ない。
2009509版から、 途中までカタカナで最後１文字が平仮名、と言う文節で確定した場合でも、 カタカナ部分だけ抽出して自動学習する様にした。

追記：
変換確定した際に、何処で切ったのかは覚えているのです。 が、例えば、
「かぞえようとしてすぱーぎあのほうを」
を
「|かぞえようとして|すぱーぎあの|ほうを|」
と区切って
「|数えようとして|スパーギアの|方を|」
と言う変換候補を当てる、と学習しても、次に、
「しゃふとについているすぱーぎあはまったく」
と入力されると、 今回入力された内容は前回学習した内容にカスりもしないので、 何処で区切ったら良いのか、判断できないのです。

ここで、辞書に単語
「シャフト」（しゃふと）
「付」（つ） ← alt-cannadic の内容を確認していないので、微妙に違うかも。
「す」（す） ← alt-cannadic の内容を確認していないので、微妙に違うかも。
「パー」（ぱー）
「ギア」（ぎあ）
「全」（まった） ← alt-cannadic の内容を確認していないので、微妙に違うかも。
が有ると、取り敢えずそれを当てはめて、
「|シャフト|に|付|いている|す|パー|ギア|は|全|く|」
と言う感じになって （厳密には大幅に間違っている。あくまで概念的イメージの話）、 付属語グラフを調べて接続できる付属語を引っ張り出してきて、
「|シャフトに|付いている|す|パー|ギアは|全く|」
と言う変換候補が作られるのです。
のすけ氏曰く「す + パーギア」は、多分これの事だと思うのです。

さて、単語登録がもうちょっと豊富で
「シャフト」（しゃふと）
「付」（つ） ← alt-cannadic の内容を確認していないので、微妙に違うかも。
「す」（す） ← alt-cannadic の内容を確認していないので、微妙に違うかも。
「パー」（ぱー）
「ギア」（ぎあ）
「スパーギア」（すぱーぎあ）
「全」（まった） ← alt-cannadic の内容を確認していないので、微妙に違うかも。
が有ると、取り敢えずそれを当てはめて、
「|シャフト|に|付|いている|す|パー|ギア|は|全|く|」
と
「|シャフト|に|付|いている|スパーギア|は|全|く|」
の２パターンが作られて （厳密には超絶に間違っている。あくまで概念的イメージの話）、 付属語グラフを調べて接続できる付属語を引っ張り出してきて、
「|シャフトに|付いている|す|パー|ギアは|全く|」
と
「|シャフトに|付いている|スパーギアは|全く|」
と言う２パターンの変換候補が作られ、 てきとーにどちらが良いのか選んで （厳密にはNovastic間違っている。あくまで概念的イメージの話）、
「|シャフトに|付いている|スパーギアは|全く|」
が提示されるのです。

ビタビの場合、結果論としては、 変換候補の各文節毎にコーパスから生成確率を取得して 総積？総乗？（Π、Product の日本語訳って何だっけ？）が 最も大きくなる候補を選ぶ、筈。
前方ｎ文節最長一致の場合、 左から順番に、 なるたけ少ない文節数でなるたけ長い文章を作れる様に選択していく。 同じ文節数で同じ長さの文章になる場合は、 前の文節の長さが短い方を選ぶ。
前方ｎ文節最長一致で MAXLEN_MODE_PUREMODE false かつ LATTICE_WITH_CAND_SCORE true にした場合、 左から順番に、 なるたけ少ない文節数でなるたけ長い文章を作れる様に選択していく。 同じ文節数で同じ長さの文章になる場合は、 各文節の辞書上の頻度値の前方加重の総和平均値が大きい方を選ぶ。

anthy-9100h + patch13Bptn23 + alt-depgraph-090506。
「|直すの|大変だよ|」（|なおすの|たいへんだよ|）
が、１発では出ない。

% egrep "^なお " alt-cannadic/gcanna.ctd
なお #F14*400 なお 尚 #R5*301 治 #S5*301 直 #CJ*300 なお 尚 #R5*300 直 #S5*300 なお 治 #CJ*200 猶 #F14*200 猶 #R5*200 なお #JN*151 なお 直 #JN*150 尚 奈緒 #JN*100 奈央 奈穂 #JN*50 奈保
% grep -w "S5" src-worddic/wtab.h
{"#S5",POS_V,COS_NONE,SCOS_NONE,CC_S5,CT_HEAD,WF_INDEP    /* "サ行五段"*/},
% cat src-worddic/ptab.h | grep -w POS_V | grep -w CC_S5 | grep -w CT_HEAD
{"サ行5段活用動詞語幹",POS_V,COS_NONE,SCOS_NONE,CC_S5,CT_HEAD,WF_INDEP},
% depgraphdump -n "サ行5段活用動詞語幹" -w "すの" -e
End: サ行5段活用動詞語幹|すの H SzC  :0.0  @_サ行5段語幹後 "" @サ行5段終止形 "す" @_5段終止形(共通) "" @「の」終助 "の" Sz@

Sz@ が付いている。
「|直すのは|大変だよ|」（|なおすのは|たいへんだよ|）
の、 助詞の省略？ 無助詞？ である上に、 句読点も省略している変則？なのだけれども。
「なおすの」「たいへんだよ」の間に文節区切りをタイプするか、 文節の長さを一旦変更してから 「なおすの」「たいへんだよ」の区切りに変更すれば、 変換できる。
でも、変換できない、と、引っかかる人が出そうな気がした。
ううむ。 文末属性を外すべきか、 文節区切りのタイプを必須とするべきか、 あるいは文末属性の処理内容を変更するか、 迷う。
文末属性の処理内容を変更する場合、 文節区切りの候補としては使用せず（この部分は、これまで通り）、 変換候補の一覧では筆頭候補にする事だけを禁止するか もしくは候補の評価を大きく下げるか（この部分を、これまでと変える）、 辺りかなぁ。

↑ Sat,16 May,2009 追記：
「丘の道を登り - 2009年05月16日 - 「|直すの|大変だよ|」」、 漏れが有ったそうです。

End: サ行5段活用動詞語幹|すの HnSeC  :0.0  @_サ行5段語幹後 "" @サ行5段連体形 "す" @_5段連体形(共通) "" Hn@「の」格助(準体) "の" Se@

このノード。

Anthy の付属語グラフを全探索するプログラム depgraphdump。
後方検索（右→左の方向での探索）も、こんな感じで完成だと思う。
「depgraphdump.cc(55KiB)」。
現状だと、 前方検索（左→右方向）時に 品詞から手動で先頭ノード名を探すのが面倒なのと、 後方検索（右→左方向）時に 先頭ノード名から手動で品詞を探すのが面倒なので、 気が向いたらおいおいその辺も実装するかもしれない。 しないかもしれない。
ただ、面倒なのと、そこまでやると 「それ何て単文節変換エンジン？」な状態になりかねず……。

Anthy の付属語グラフに於いて、 各品詞の根ノードがどうやって決まるかの話。


前提知識： wtype_t は pos, cos, scos, cc, ct, wf の集合。

付属語を付加しようとしている単語に関して、 ptab.h の全てのノードに対して src-worddic/wtype.c の anthy_wtype_include( 「ptab.h のノードの wtype_t」, 「単語の wtype_t」 ) にて 一致するか否かの判定を行い、 「一致」と判定されたノード全てが使われる。
複数のノードが一致と判定された場合、 一致と判定された全てのノードが使用される。

＃ 単語の wtype_t は、単語の品詞から wtab.h を使って決める。

判定では、

• pos, cc, ct, cos, scos が使われ、wf は使われない。
• ptab.h で *_NONE と指定された項目は、判定に用いない（ワイルドカード）。
• ptab.h で *_NONE 以外の指定をされた項目は、 単語の wtype_t（wtab.h）でも同じ指定になっていないと、不一致と判定される。
• 単語の wtype_t（wtab.h）で *_NONE と指定された項目は、 ptab.h でも *_NONE になっていないと、不一致と判定される。

• 付属語の有無（WF_INDEP なら付属語有り），
• 候補に連用形の名詞化を追加する（WF_MEISI），
• コーパス検索時の分類に使用 ＆ 接尾辞の有無（WF_SV），
• 未使用（WF_AJV），

C/C++ の構造体のビットフィールドで、よくある誤解。
anthy_wtype_include を web で検索してみたら。 「Rubyのある風景 - AHG_BitOperation」 と言う記事を見つけたのだけれども。
残念ながら、 C/C++ の構造体のビットフィールドがどの様にパッキングされるのかは コンパイラ／アキーテクチャ依存なので、 それはやってはいけないのですね。

まぁ、引用元の著者氏も、 環境によって変わってしまう事を承知してやっている様ですが。
＃ もっとも、
＃ 必須要件：
＃ ××と言うアーキテクチャの計算機の××と言うＯＳで ××と言うコンパイラの××バージョンを ××と言うオプションで使用する事。
＃ と書いてしまえば、 適切に動作しようが暴走しようが「仕様」になるので、 問題は無かったりしますが。

例えば、
 |ffff|eeee|ddddd|ccccccc|bbbb|aaaaa|ppp|
 |wf  |ct  |cc   |scos   |cos |pos  |pad|
こう言う詰め方をされるかもしれないし。
 |0が28bit|ffff|eeee|ddddd|ccccccc|0が4bit|bbbb|aaaaa|ppp|
 |        |wf  |ct  |cc   |scos   |       |cos |pos  |pad|
あるいはこうかもしれないし。
 |0が59bit|ppp|0が57bit|aaaaa|0が58bit|bbbb|0が55bit|ccccccc|0が57bit|ddddd|0が58bit|eeee|0が58bit|ffff|
 |        |pad|        |pos  |        |cos |        |scos   |        |cc   |        |ct  |        |wf  |
こうなるかもしれない。
 |0が58bit|ffff|0が58bit|eeee|0が57bit|ddddd|0が55bit|ccccccc|0が58bit|bbbb|0が57bit|aaaaa|0が59bit|ppp|
 |        |wf  |        |ct  |        |cc   |        |scos   |        |cos |        |pos  |        |pad|
こうかもしれない。

Anthy の付属語グラフの文末属性をチェックする方法。 「丘の道を登り - 2009年05月16日 - 「|直すの|大変だよ|」」、 に関して。
手持ちの学習結果の OCHAIRE を使えば、 チェックできるかなぁ。
問題は、 以前、CAND_HISTORY 学習から 付属語付加の可否を見てみた時の状況から考えると、 大量に出てくる「付加不能」判定から、 元にした OCHAIRE が間違えていてそうなった物や、 個人用の単語登録を使用している為にそうなった物や、 仕様変更（助詞を別文節に分離）に伴いそうなった物と、 付属語グラフの漏れや間違いでそうなった物を、 どうやって区別したら良いのか。   付加不能判定が 1000件くらい出ても、 そのうち漏れや間違いが原因の物は 10件も無かったりするから……。

↑ 変換する perl スクリプト自体は難しくない。 各種 version/variant 対応にするのは面倒だしどうせ誰も使わないので、 拙作patch22以降専用。
CAND_HISTORY から変換するスクリプトは手抜きで、 手動で last-record1_default から CAND_HISTORY セクションだけ 切り出してやらないといけなかったが、 今度はそこも全自動。
% ./anthy_ochaire2corpus.pl < ~/.anthy/last-record1_default > /tmp/corpus.ochaire.txt
とかやるだけ。

#!/usr/bin/perl --
#
# Anthy: Converter, from OCHAIRE to corpus.txt.
#	Sat,16 May,2009
#	Copyright(C)2009 G-HAL (fenix.ne.jp)
#
use encoding "EUC-JP";
use strict;

{
	my $output_mode = "";

	while () {
		chomp( $_ );
		my $input = $_;
		if ($input =~ /^--- (\w*)$/i) {
			$output_mode = $1;
		} elsif ($output_mode eq "OCHAIRE") {
			if ($input =~ /^\+([^ ]+) ([0-9]+) (.+?) ([-]*[0-9]+) ([-]*[0-9]+) ([-]*[0-9]+) ([-]*[0-9]+) ([-]*[0-9]+) (T[0-9]+ F[0-9]+)$/) {
				my $ochaire_key  = $1;
				my $ochaire_len  = $2;
				my $ochaire_core = $3;
				my $ochaire_ka   = $4;
				my $ochaire_wI   = $5;
				my $ochaire_woI  = $6;
				my $ochaire_woD  = $7;
				my $ochaire_wD   = $8;
				if ((2 == $ochaire_len) and (0 != $ochaire_wI) and (0 != $ochaire_wD)) {
					if ($ochaire_core =~ /^([0-9]+) "([^"]+)" ([0-9]+) "([^"]+)"$/) {
						my $p1_len  = $1;
						my $p1_cand = $2;
						my $p2_len  = $3;
						my $p2_cand = $4;
						print "|". substr($ochaire_key,0,$p1_len) ."|". substr($ochaire_key,$p1_len,$p2_len) ."| |". $p1_cand ."|". $p2_cand ."|\n";
					}
				}
			}
		}
	}

	exit 0;
}

__END__
# [ EOF ]

……20分後……。
結果、駄目だった。 読み仮名指定部分で文節区切り位置を明示している為、 文末属性をキャンセルするモードになっている。 まぁこれは、ソースをいじれば変えられる。
それだ。どれだ。
文末属性を無視する状態と、文末属性を使用する状態の、違いを見れば、 文末属性の影響により変換できなくなった部分が判る。 1000件とか出てこられて探すよりは、多分楽になる筈。
……20分後……。
入力件数が約37000件、変換できなかった物が約1300件、 変換できなかった物のうち文末属性由来の物が18件だった。 これなら人力で確認できる。

つぶれたよ              |つぶれたよ|てんてん|           |潰れたよ|……|
ひつようだよなぁ        |ひつようだよなぁ|てんてん|     |必要だよなぁ|……|
ほうほうだろうなぁ      |ほうほうだろうなぁ|てんてん|   |方法だろうなぁ|……|
ほすんですか            |ほすんですか|てんてん|         |干すんですか|……|

この辺りは仕方が無い。文末属性に引っかかって当然。
「……」の読み仮名を「／／／」や「。。。」などにすれば解決できる。


まぜるな                        |まぜるな|きけん|               |混ぜるな|危険|
しゅうりょうですか              |しゅうりょうですか|そうですか| |終了ですか|そうですか|
しようですか                    |しようですか|そうですか|       |仕様ですか|そうですか|
ちゅうどくですか                |ちゅうどくですか|そうですか|   |中毒ですか|そうですか|

これも意図的に文末の直後に文を書いている内容なので、引っかかって当然。
文節区切り位置を変更して学習すれば良し。


かなしみよ                      |かなしみよ|こんにちは|                 |悲しみよ|こんにちは|           End: 名詞35|よ H SzC  :0.0 @_名詞35のあと "" @「よ」終助 "よ" Sz@
おくるべきか                    |おくるべきか|おくらない|               |送るべきか|送らない|           End: ラ行5段活用動詞語幹|るべきか H SzC  :0.0 @_ラ行5段語幹後 "" @ラ行5段終止形 "る" @_5段終止形(共通) "" @_助動「べし」 "" @助動「べし」連体形 "べき" @「か」終助 "か" Sz@
おこなうべきか                  |おこなうべきか|いなか|                 |行うべきか|否か|               End: ワ行5段活用動詞語幹|うべきか H SzC  :0.0 @_ワ行5段語幹後 "" @ワ行5段終止形 "う" @_5段終止形(共通) "" @_助動「べし」 "" @助動「べし」連体形 "べき" @「か」終助 "か" Sz@
かうべきか                      |かうべきか|いなか|                     |買うべきか|否か|               同上
かんがえるべきか                |かんがえるべきか|あぐねて|             |考えるべきか|あぐねて|         End: 上下一段活用動詞語幹|るべきか H SzC  :0.0 @_上下一段語幹後 "" @上下一段終止形 "る" @_上下一段終止形(共通) "" @_助動「べし」 "" @助動「べし」連体形 "べき" @「か」終助 "か" Sz@
どうするべきか                  |どうするべきか|まよう|                 |どうするべきか|迷う|           End: 副詞12|するべきか H SzCs :0.0 @_副詞12のあと "" @_補動「する」 "" Cs@補動「する」終止形SR "する" @_助動「べし」 "" @助動「べし」連体形 "べき" @「か」終助 "か" Sz@
                                                                                                        End: 名詞30|するべきか HvSzCs :0.0 @_名詞30のあと "" Hv@_補動「する」 "" Cs@補動「する」終止形SR "する" @_助動「べし」 "" @助動「べし」連体形 "べき" @「か」終助 "か" Sz@
へんかんするべきか              |へんかんするべきか|くぎらずに|         |変換するべきか|区切らずに|     End: 名詞30|するべきか HvSzCs :0.0 @_名詞30のあと "" Hv@_補動「する」 "" Cs@補動「する」終止形SR "する" @_助動「べし」 "" @助動「べし」連体形 "べき" @「か」終助 "か" Sz@
ねっきょうしているからか        |ねっきょうしているからか|ほんとうに|   |熱狂しているからか|本当に|     同上

この辺りは私では判断が付かない。
vagus氏に頼むしか手が無い……。

↑ 意図的に文末の直後に続けて文を書く事が有る事が判った。 と言うより、今更気付いた。
となると、現状の実装のまま、 文末属性の後に文を続けるのを、 文節区切りと候補の提示の両方で完全に禁止するのは、 やっぱりまずそう。
考えられる方策としては、 文節区切りのアルゴリズムに対して、

• 全面禁止。文節区切り位置を手動指定時のみ許可。（現状）
• スコアを下げる。
  • 大きく下げる。
  • 小さく下げる。
• 全面許可。

• 全面禁止。文節区切り位置を手動指定時のみ許可。（現状）
• スコアを下げる。
  • 大きく下げる。
  • 小さく下げる。
  • 筆頭候補にする事だけを禁止する。
• 全面許可。

Anthy の文末属性の話、昨日の続き。
と、言う訳で、文末属性による除外条件が該当した場合、 文節区切りは全面禁止（手動指定時を除く）、 変換候補の並び順ではスコア半減（手動指定時を除く）、 に変更してみた。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」、 patch13Bptn23.2009517 に更新。

↑ 例えば、「まぜるなきけん」を変換すると、 「|混ぜるな|」が文末属性で後ろに「きけん」が続くので、 従来だと「|混ぜるな|」と言う候補が使用禁止になって、 完全に消えてしまう。
もし文節の区切り方が「|まぜるな|きけん|」だけしか存在しない場合 （実際には他にも有るけれど）、 「|まぜるな|」の部分の変換候補に 「|混ぜるな|」が出てこなくなってしまう。
2009517 だと、 文節の区切り方が「|まぜるな|きけん|」だけしか存在しない場合は、 「|まぜるな|」の部分の変換候補に 「|混ぜるな|」がスコアは低いけれども出てくる。
従来版でも 2009517 でも、 文節区切り位置を手動で「|まぜるな|きけん|」と指定した場合や、 学習でそう区切ると判定した場合は、 「|混ぜるな|」が普通のスコアで出てくる。

Anthy + patch13Bptn23.2009517 の問題。
「nosuke(のすけ)氏 - 日記みたいな何か - 2009年 5月18日 (月) - でんしゃ」、 『「電子ゃ」が変換候補一覧の最初に来てしまう』。
スコアを下げておけば問題にならないだろうと思ったら、 学習して、下がったスコアが上がってしまい、 問題が再発したオチ。
さて、これはどう対策するべか。
明日に続く。

Anthy + patch13Bptn23.2009517 の問題、昨日の続き。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」

スコアを下げたつもりだったのだが、 文節区切りでのスコアは下がっていたが、 変換候補の一覧でのスコアが下がっていなかったオチ orz。
「っ」「ー」「゛」の場合と、 「ぁ」「ぃ」「ぅ」「ぇ」「ぉ」で且つ直前の文字の韻を踏んでいる場合は、 変換候補のスコアは半減、自立語部分一致での学習の適用を許可。
「ゃ」「ゅ」「ょ」「ゎ」の場合と、 「ぁ」「ぃ」「ぅ」「ぇ」「ぉ」で且つ韻を踏んでいない場合は、 変換候補のスコアは最低点、自立語部分一致での学習の適用は禁止 （文節全体で完全一致した場合のみ、学習適用を許可）。
にしてみた。

具体例：
「電子」（でんし）が学習してある場合。
「電子ぃ」（でんしぃ）や「電子っ」（でんしっ）は、 「電子」（でんし）の半分のスコアで、 且つ自立語部分が「電子」（でんし）の学習の結果を受け継ぐ。
「電子ゃ」（でんしゃ）や「電子ゎ」（でんしゎ）などは、 変換候補の順番では最後尾群で、 且つ自立語部分が「電子」（でんし）の学習の結果を受け継がない。

↑ そして。
Anthy の meta_word の仕様で誤解している部分が有り、 語尾に XCT_PART を追加した単語にて、 学習の適用間違いや ENABLE_ERROR_RECORD での誤判定が 起きる可能性が有る事を発見。
meta_word 構造体に格納されている単語の合計長は、 meta_word.len よりも短い場合が有るらしい。 その場合の不足している部分は、入力された内容と同じ、らしい。
meta_word の比較ルーチンを丸ごと書き直し中。

↑*2,*1 拗音処理部分の修正／変更／追加よりも、 meta_word 比較の実装し直しの方が手間取っていたりする。

Anthy の、 ビタビアルゴリズムでのコーパス処理を人力で調整できるのだろうか、 あるいはどの様に処理されているのか、辺りの話。

まず、コーパスで処理される構造としては、「|修正できるだろう|」が、

  文頭
  POS_NOUN,COS_NONE,SCOS_T30,CC_NONE,CT_NONE,WF_INDEP|WF_SV + "動詞+終端" + "終端" + "できるだろう"
  文末

の構造になっていて、「|修正で|切るだろう|」が

  文頭
  POS_NOUN,COS_NONE,SCOS_T30,CC_NONE,CT_NONE,WF_INDEP|WF_SV + "名詞+格助詞" + "格助" + "で"
  POS_V,COS_NONE,SCOS_NONE,CC_R5,CT_HEAD,WF_INDEP + "動詞+終端" + "終端" + "るだろう"
  文末

の構造になっている模様。


この構造からビタビでの確率計算は、「|修正できるだろう|」が、

    「(文頭 → 動詞+終端) + (POS_NOUN,COS_NONE,SCOS_T30,CC_NONE,CT_NONE,WF_INDEP|WF_SV) + hash(できるだろう) + (終端)」
  ×「(動詞+終端 → 文末) + () + hash() + ()」

の値になり、「|修正で|切るだろう|」が

    「(文頭 → 名詞+格助詞) + (POS_NOUN,COS_NONE,SCOS_T30,CC_NONE,CT_NONE,WF_INDEP|WF_SV) + hash(で) + (格助)」
  ×「(名詞+格助詞 → 動詞+終端) + (POS_V,COS_NONE,SCOS_NONE,CC_R5,CT_HEAD,WF_INDEP) + hash(るだろう) + (終端)」
  ×「(動詞+終端 → 文末) + () + hash() + ()」

の値になる。


コーパスを無効にすると１文節になって、コーパスを有効にすると２文節になるので、
コーパスでの処理の結果、
    「(文頭 → 動詞+終端) + (POS_NOUN,COS_NONE,SCOS_T30,CC_NONE,CT_NONE,WF_INDEP|WF_SV) + hash(できるだろう) + (終端)」
  ×「(動詞+終端 → 文末) + () + hash() + ()」
よりも、
    「(文頭 → 名詞+格助詞) + (POS_NOUN,COS_NONE,SCOS_T30,CC_NONE,CT_NONE,WF_INDEP|WF_SV) + hash(で) + (格助)」
  ×「(名詞+格助詞 → 動詞+終端) + (POS_V,COS_NONE,SCOS_NONE,CC_R5,CT_HEAD,WF_INDEP) + hash(るだろう) + (終端)」
  ×「(動詞+終端 → 文末) + () + hash() + ()」
の方の値が大きくなっている模様です。


取り敢えず、１文節で「(名詞30)できるだろう」の型の
コーパス（全く同じ内容でも良い筈）を100個ぐらい増やせば、
変わるかもしれない様な気もしなくはないですが。変わらないかもしれない。

コーパスで処理されている段階のデータに対して、穴埋めして文章を作ると考えると、
１文節も２文節も、どちらも適切な文章になるので、
「どうしようもない」と思われます。


備考：
確率計算で用いる付属語の内容は、ハッシュ値に変換して用いられる。
従って、全然違う付属語と一致してしまっている可能性も否定は出来ない。

Anthy + patch13Bptn23.2009517 の問題、一昨日の続き。
たぶん、こんな感じで良いと思うのだけれども。
最適化が甘い部分が有ってちょっと気になるけれども、いじるのやめた。 ドツボにハマってエンバグ繰り返す方が怖い。 そもそも、 今回いじらなかった部分で最適化が大甘な部分が山盛りな上に、 （以下検閲削除）。   あと、ディスクが溢れて滅多に使わない物を消していたら、 間違ってコンパイラまで消してしまった罠。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」、 patch13Bptn23.2009520 に更新。

日本語入力関連で、 最近雑誌や web でしばしば見かける誤解を招く恐れの有る表現。 Mon,25 May,2009に続く。

『Anthy（の辞書）を EUC-JP にすると 「もりおうがい」の漢字が入力できないが、 Anthy（の辞書）を UTF-8 にすれば入力できる。』 と言う主旨の記事を見かけるが、記事の文面だけを見ると、 EUC-JP が悪いせいで入力できず、UTF-8 は良いから入力できる、 と誤解しかねない書き方を見かける事が有る。
短く事実だけを述べたのか、 擁護しているのか、 あるいは著者自身も誤解しているのか。
誤解しようが無い書き方をしようとすると。
Anthy の EUC-JP の処理は、 JIS X 0208｛大雑把に言うと EUC-JP のサブセット（縮小版）｝のみ対応で、 JIS X 0212｛大雑把に言うと EUC-JP のフルセット。補助漢字対応。｝や JIS X 0213｛大雑把に言うと EUC-JP のフルセットの別バージョン。第三・第四水準漢字、補助漢字対応。｝に 非対応。 Anthy の UTF-8 の処理は、 JIS X 0208 と JIS X 0212（補助漢字）の両方に対応 （適切に UTF-8 対応にすれば、勝手にそうなる）。 「もりおうがい」の漢字は JIS X 0212 漢字なので（あとは省略）。

Unicode で JIS X 0213（第３／第４水準漢字）に対応なのか非対応なのかは、 Unicode のバージョンによって違うが、 Anthy の Unicode 対応がどのバージョンの Unicode なのかは不明。   細かい事を言うと、Anthy は UCS-4 を int型に格納しているので、 そもそも UCS/Unicode への対応ができていないとか （Ｃ言語の規格を厳格に解釈した場合）、 Unicode ver.3.0 までの対応で JIS X 0212（補助漢字）は対応だけれども JIS X 0213（第３／第４水準漢字）は一部非対応になるとか （Ｃ言語の規格をゆるめに解釈した場合）、 Unicode ver.5.0 まで全て対応しているとか （amd64/i386系の計算機で gcc を使うと、 実際の運用としてはこうなる場合が多い）、 どの言い方でもできるけれど、どれも誤解を招く言い方であって。   JIS X 0213 完全対応になる Unicode のバージョンだと、 結合文字とかサロゲートペア（UTF-16/UCS-2 の場合）だとかへの対応が 必須になるらしい。
EUC-JP だと JIS X 0212 と JIS X 0213 の両方に同時に対応する事は できず（ISO-2022 から、 多規格への対応機能を省略して簡略化したのが EUC-JP だから）、 JIS X 0212 と JIS X 0213 の両方に同時に対応したければ ISO-2022 か UCS/Unicode にするしかない……と思ったが、 JIS X 0213 は、実用上は問題無い程度には JIS X 0212 を内包しているのか。 あとは JIS X 0212 の EUC-JP と JIS X 0213 の EUC-JP で、 文字コードの変換が必要な問題 （JIS X 0212 EUC-JP で書いたファイルは JIS X 0213 EUC-JP に変換しないと 第３／第４水準漢字を使えない。 JIS X 0213 EUC-JP で書いたファイルは、 JIS X 0208/0212 EUC-JP のみ対応のソフトウェアでは扱えない）が。
JIS X 0212/0213 対応／非対応が良い／悪いとかでは無く。 ｛対応／非対応は単なるソフトウェアの仕様の問題で、 利用者が自分の要求仕様に見合ったソフトウェアを使えばいいだけの話。 （学習量が多かろうが少なかろうが、それも仕様の一部。 仕様が気に入らなければ、 要求仕様に見合う別のソフトウェアに乗り換えるなり、 それがそのソフトの存在意義に関わるならばその旨の要望を出してみるなり、 要求仕様に見合う様に改造するなり、するだけ）｝
事実を誤解しない様に、と言う話。

それはともかく。
JIS X 0208 のみ対応で JIS X 0212/0213 非対応な EUC-JP のソフトって わりとあるし。 有名な？所で kterm ……kterm は10年も前から JIS X 0212/0213 対応パッチが公開されていた…… とか vim系とか。 Solaris の 2007年よりも前の版も JIS X 0213 EUC-JP は非対応だし。 GNU/Linux も数年だか５年だか前までは JIS X 0213 EUC-JP 非対応のディストリビューションが多かったし。

日本語関連の誤解に関しては、それ以外にも、色々と。
「いわゆる半角カナ」は 「いわゆる全角文字」と同じ幅で表示しても構わないし、 「いわゆる全角文字」を 「いわゆる半角カナ」と同じ幅で表示しても構わない、 （どちらも規格に適切に従っており、何ら違反は無い。 嫌とか言い出したら、プロポーショナルフォント使うな、と言う話に 飛び火しかねない） （あと、 EUC-JP での 0xA1F1, 0xA1F2, 0xA2CC 辺りのいわゆる全角文字は、 UCS/Unicode では U+00A2, U+00A3, U+00AC のいわゆる半角文字になり、 文字コードを変換しただけなのに、 いわゆる全角文字といわゆる半角文字が入れ替わってしまう）、 件とか。
規格では、 「半角カナ」とか「半角文字」とか「全角文字」とか いう言葉は定義されていない（そんな言葉は存在しない）件とか。

Anthy-9100? 系で、 mkworddic/name.t の「とうしょうへい」の漢字のコードが 間違っているのを見つけた。

• （PC-9801末期およびPC-9821での独自拡張文字） JIS風表記だと 1面 91区 93点 0x7B7D、 ISO-2022風表記だと 1B 24 28 44 62 47 1B 28 42、 EUC-JP風表記だと 0xFBFD、 ShiftJIS風表記だと 0xEE9D、 UCS/Unicode では未定義。
• JIS X 0208、JIS X 0212、JIS X 0208 EUC-JP、JIS X 0212 EUC-JP、 等では表記不可能（漢字が存在しない）。
• JIS X 0213 1面 92区 80点 0x7C70、 ISO-2022 だと 1B 24 28 51 7C 70 1B 28 42、 JIS X 0213 EUC-JP だと 0xFCF0、 JIS X 0213 ShiftJIS だと 0xEEEE、 UCS/Unicode（バージョンは調べていない）だと U+9127、 UCS-4 だと 0x00009127、 UTF-8 だと E9 84 A7。
• ISO-2022-CN, EUC-CN, EUC-TW、UCS/Unicode の中国／台湾の漢字。 文字コードは、iconv を信じるならば、 ISO-2022 では 1B 24 29 47 0E 6F 52 0F、 EUC-CN では該当無し、 EUC-TW では 0xEFD2、 UCS/Unicode（バージョンは調べていない）だと U+9127、 UCS-4 だと 0x00009127、 UTF-8 だと E9 84 A7。

Anthy の辞書を EUC-JP にすると 第３／第４水準漢字とか補助漢字とかが使えないのは Anthy が対応していないからであって、 EUC-JP 自体は第三・第四水準漢字とか補助漢字とかに対応している、 と言う話、 Sun,24 May,2009の続き。
勢いと伊達と酔狂で、 Anthy を JIS X 0213 EUC-JP に対応させてみた。
uim が JIS X 0213 EUC-JP 非対応で蹴られた （JIS X 0212 EUC-JP で表記できない文字が消える）。
終わった……。燃え尽きたよ、真っ黒に。

JIS X 0212 EUC-JP モードにすれば、 uim も対応しているし、補助漢字は使える様になるけれども、

UTF-8 な uim にて、 辞書は JIS X 0213 EUC-JP で、端末エンコーディングは UTF-8、 とか言う事はできる筈。 辞書サイズが UTF-8 な辞書よりも２〜３割小さくなるけれども、 文字コード変換の分 （UTF-8 → ホストエンディアンUCS-4 変換よりも、 EUC-JP → ホストエンディアンUCS-4 変換の方が、 たぶん負荷が高い）だけ処理がちょっと遅くなるかもしれない。 正直、 辞書を JIS X 0213 EUC-JP にして嬉しい事が有るかどうかは微妙、 もしかしたら無いかも。   あと、燃え尽きたので動作は未確認。

単に、uim の anthy.scm にて、 JIS X 0201/0208/0212 EUC-JP しか 通さない設定になっているだけだった。
anthy.scm の最後の方にある register-im の中の "EUC-JP" を "EUC-JISX0213" に書き換えたら、 あっさり JIS X 0201/0208/0213 EUC-JP も通った。
これで、 辞書 → anthy → uim までは 全部 JIS X 0213 EUC-JP で通る様になった。

試しに uim → XIM → アプリケーション の方も JIS X 0213 EUC-JP にしてみたら。
未確定状態での表示が豆腐になった。
それから、 kterm とか mlterm のターミナルでは一応通ったけれども、 入力直後の表示が \U+F4BA とかなってしまう。 ターミナル上で動かしているアプリケーションへの入力は 正しくなっていたし、 画面再描画するとちゃんと表示されるけれども。
GTK方面だと、 「WARNING **: Error converting text from IM to UCS-4: 変換する入力に無効なバイトの並びがあります」 とエラーが表示されて蹴られた。 GTK2 の GTK_IM_MODULE の gtkimcontextxim.c から GLIB の g_conv を呼び出している部分。

未確定が豆腐になったり表示がこけたりエラーが出て蹴られるのは、 どれも、 ToolKit側での LANG=ja_JP.eucJP の場合の XIM の コーディング設定が eucJP （EUC-JP にて JIS X 0212 か JIS X 0213 のどちらなのかを指定しないと、 多くの iconv では JIS X 0212 の EUC-JP になる）になっていて、 そこに JIS X 0213 EUC-JP が入ってきたからおかしくなっていた。   荒技として、iconv で eucJP を選択した場合のコーディングを JIS X 0213 EUC-JP に変更しておけば解決できる事は判るのだけれども、 別の問題が出るし。 私以外に実行する人がいないとか、政治的な問題とか。   泥沼になりそうなので、これ以上突っ込まない方が良さそうだ。


ともかくも。
辞書 → anthy → uim は JIS X 0213 EUC-JP で、 uim → XIM/GTK_IM_MODULE → アプリケーション は JIS X 0213 UTF-8、
もしくは
辞書 → anthy は JIS X 0213 EUC-JP で、 anthy → uim → XIM/GTK_IM_MODULE → アプリケーション は JIS X 0213 UTF-8、
とか言う事が安定的にできる様になったけれども。
やっぱり、 辞書を JIS X 0213 EUC-JP にして嬉しい事が有るかどうかは微妙。   ネットブックみたいなディスク容量が小さいマシンでは、 辞書が小さくなる辺り、もしかしたら嬉しいかもしれない……、 でもたかだか 2〜3MiB くらいなんだよなぁ。

↑ 追補。
Anthy の EUC-JP で JIS X 0212/0213 が使えない問題は、 Anthy 内蔵の文字コード変換エンジンが JIS X 0201/0208 専用 （入力される EUC が２バイト固定である前提で作られている）で、 JIS X 0212/0213 非対応である所から来ている。   それ以外にも、anthy-agent にて EUC のシングルシフトに非対応な問題も有るが、 かな漢字変換エンジン本体には影響しない。
なので、 Anthy内の文字コード変換エンジンを JIS X 0212/0213 対応の物に 交換してやれば、取り敢えずは対応できる。   上記の拙作の JIS X 0213 対応の物は、 文字コード変換エンジンを libiconv に変更する事で実現した。
但し、 Anthy の内部処理用の文字コードの UCS-4 関連の実装が ホストエンディアン UCS-4 になっており、 GNU/Linux glibc版 iconv はホストエンディアン UCS-4 に非対応なので、 GNU/Linux の場合は 単純に iconv に交換するだけでは JIS X 0212/0213 対応にできない。   エンディアン変換すれば GNU/Linux glibc版 iconv でも対応できるけれど。 別途 libiconv版 iconv をインストールすれば解決するし、 需要が無いのにやってもねえ……。

Anthy 拙作パッチのバグ、 「vagus氏 - 丘の道を登り - 2009年05月27日 - 正変換の候補の中に逆変換の候補が混じることに気づいた」、 の件。

要因解説：
システム辞書の単語の評価値は、 原作版 Anthy では、 辞書のソースに書かれている値を参考に Anthy が適当に勘案した値になっていた。
拙作パッチの patch12/13ptn12 (Sat,22 Nov,2008) から、 辞書のソースに書かれている頻度値を直接用いる様に変更したが、 その際、 辞書のソースに書かれている頻度値が小さい場合に システム辞書の各単語の逆変換フラグが壊れていた。
どうやら、 頻度値の下限は 内部表記の 100（拙作パッチでの換算では、辞書のソース上での 8）で、 これを下回るとシステム辞書のファイルに記録される頻度値が 0 になり、 逆変換フラグ（頻度値の符号がそのまま逆変換フラグになっているらしい）が 喪失するらしい（整数型の 0 には符号が無い）。

対策：
辞書のソースに書かれている頻度値から システム辞書のファイルに記録する頻度値への計算方法を変更して、 小さい頻度値の場合でも逆変換フラグを喪失しない様にした。

副作用：
辞書のソースにおける頻度値の上限が 4095 （たぶん。 int型のデータ長の下限保証値って幾つだっけ？ ……具体的数量は定義されていないか。） になった。 なお、非保障（仕様外）だが、 int型が 32bit なシステムでは 268427264 まではトラブルは起きない。
…… int型が 16bit なシステムだと頻度値上限 4095 だけれど、 int型が 16bit だと原作版 anthy 由来部分の そこかしこでトラブルやデータ破壊が起きるから意味無いか。
そう言えば、int型が 14bit なマイコンも有るなぁ。 その場合は 1023 が上限。 マイコンで anthy を動かす奴がいるとは思えんけどな。
備考：
この下限値 100 は、 ソースのあちこちにバラバラにハードコーディングされていた。
ヘッダファイルでの const int か #define での 定義にまとめるべきだが、どの 100 が該当して、 どれが該当しないのかよくわからないのでやめた。

前置きが長い上に脱線したけれども、 「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」、 patch13Bptn23.2009527 に更新。

↑ それはともかくも。 全然気付いていませんでした。 御指摘、有り難うございます。
私の場合、 記号類をタイプする寸前に変換して確定し、 記号類は無変換で入力して変換無しで確定するクセがあるので、 発症する状況になった事がありませんでした。

「vagus氏 - cannadic改 - alt-depgraph-090525 に同梱の configure.ac」
> AC_CONFIG_MACRO_DIR([m4])dnl Added by vagus, Sun,24 May,2009
を追記。 Thanks to vagus.

anthy + uim を JIS X 0213 EUC-JP（第３・４水準漢字、補助漢字）に対応させてみる話。
そんなこんなで、気付かない内に？
辞書 → anthy → uim は JIS X 0213 EUC-JP で、 uim → XIM/GTK_IM_MODULE → アプリケーション は JIS X 0213 UTF-8、
もしくは
辞書 → anthy は JIS X 0213 EUC-JP で、 anthy → uim → XIM/GTK_IM_MODULE → アプリケーション は JIS X 0213 UTF-8、
とか言う事が実現できていたので、 Mon,25 May,2009を修正。

Anthy の EUC-JP の正体。
Anthy の内蔵の EUC-JP - UCS-4 変換エンジンと、 libiconv で、 変換結果が違う物が有る事に気付いた。
具体的には、 UTF-8 な単語辞書をテキストエディタで編集し、 Anthy で読み込んで、ロケールを ja_JP.eucJP にして入力すると、 一部の記号が文字化けしてしまう。 逆に、 Anthy用辞書ツールで UTF-8 な private_words_default に 単語登録して、 単語辞書をテキストエディタで編集しようとすると、 文字化けしている。
いやまあ、文字化けする事自体は、 Anthy を初めて使った時に、 Canna のユーザ辞書を変換して突っ込んだら文字化けしたので、 気付いてはいたのだけれども。
ようやく原因が判明。

文字化けしたのは、概ね下記の記号類。 １面85区〜94区のマッピングを見れば EUC-JP/EUC-JP-MS/CP51932/EUC-JISX0213 の区別が付くらしいので、 それも調べてみた。

文字コード比較

文字名	文字	EUC-JP	AnthyでのUCS-4	JISで定義されたUCS-4
EM DASH	―	0xA1BD	U+2015	U+2014
WAVE DASH	〜	0xA1C1	U+FF5E	U+301C
DOUBLE VERTICAL LINE	‖	0xA1C2	U+2225	U+2016
MINUS SIGN	−	0xA1DD	U+FF0D	U+2212
CENT SIGN	¢	0xA1F1	U+FFE0	U+00A2
POUND SIGN	£	0xA1F2	U+FFE1	U+00A3
NOT SIGN	¬	0xA2CC	U+FFE2	U+00AC
丸付数字		0xADA1〜	U+2460〜	X 0208/0212には存在しない文字。X 0213では U+2460〜
１面85区〜94区		0xF5A1〜0xFEFE	U+E000〜U+E3AB	X 0208/0212には存在しない文字。X 0213では U+64C4 など

……、Anthyのこのマッピングは EUC-JP-MS ですな。
ここまで見事に EUC-JP-MS になっていると言う事は、 わざと EUC-JP-MS にしたと考えるのが妥当だと思うけれど。
anthy-7900 → anthy-8300 の辺りで UCS-4 がらみが実装されたっぽいが、 2006年７月に初めて実装された時からずっと、 EUC-JP-MS だったらしい。

なぜ EUC-JP-MS なのだろう。
WinAnthy がらみ？…… WinAnthy の初版が公開される１年以上前からずっと EUC-JP-MS だったから、 それは無いか。 当時の mailing list のログを見ても、 この事に関する情報は見つからず。
scim だと、 2006年７月21日の scim-antny-1.2.0 にて、 Anthy に対して想定する文字コードを EUC-JP から EUC-JP-MS に変えた、みたいな事が書いてあるが、 これは、 Microsoft Office / MS-Windows用 OpenOffice と Unix系 OpenOffice での「〜」の文字化けがらみがどうのこうの、 と Mailing-list に書いてあったので、 Anthy がどうと言う訳では無いっぽい。
uim-anthy だと、 現在でも EUC-JP(JIS X 0208/0212) を前提にしている。

謎だ。

Anthy の alt-depgraph の違いや辞書の文字コードの違いで、 変換速度にどの程度の違いが出るのか。
何となく気になったので、なんとなく調べてみた。
比較対象は、 anthy-9100h ＋ 拙作パッチ patch13Bptn23.2009520 に、 alt-depgraph-090506 を使用した場合と、 alt-depgraph-090525 を使用した場合。 変換内容は、 alt-depgraph-090525 の calctrans/corpus.x.txt の 読み仮名部分を切り出した 1165件。 変換結果が望ましいものか否かの判定は行わない。

PentiumD 3.2GHz, SingleCore, Disable HyperThreading, 省電力モード無し
OpenBSD/amd64 4.4-RELEASE
コンパイラ：gcc 3.3.5
コンパイルオプション：-g3 -O0
変換アルゴリズム：ビタビアルゴリズム

patch13Bptn23.2009520.alt-depgraph-090506 辞書 EUC-JP-MS、alt-cannadic/extra 無し、辞書サイズ 18398776
ユーザランドの処理時間［秒］、カーネル空間の処理時間［秒］、実行終了までの延べ時間［秒］
30.468u 0.656s 0:31.44
30.281u 0.726s 0:31.12
30.476u 0.578s 0:31.12

patch13Bptn23.2009520.alt-depgraph-090506 辞書 UTF-8、alt-cannadic/extra 無し、辞書サイズ 21444600
30.132u 0.687s 0:30.92
30.148u 0.531s 0:30.77
30.039u 0.695s 0:30.88

patch13Bptn23.2009520.alt-depgraph-090506 辞書 UTF-8、alt-cannadic/extra 有り、辞書サイズ 21750200
30.210u 0.570s 0:30.88
31.218u 0.601s 0:31.88
30.132u 0.585s 0:30.85

patch13Bptn23.2009520.alt-depgraph-090506 辞書 EUC-JISX0213、alt-cannadic/extra 有り、辞書サイズ 18651832
30.632u 0.492s 0:31.30
30.484u 0.632s 0:31.20
30.375u 0.664s 0:31.21

patch13Bptn23.2009520.alt-depgraph-090525 辞書 EUC-JP-MS、alt-cannadic/extra 無し、辞書サイズ 18093224
29.937u 0.484s 0:30.53
29.773u 0.671s 0:30.50
29.929u 0.609s 0:30.62

patch13Bptn23.2009520.alt-depgraph-090525 辞書 UTF-8、alt-cannadic/extra 無し、辞書サイズ 21138856
30.226u 0.570s 0:30.91
30.046u 0.546s 0:30.68
30.164u 0.640s 0:30.88

anthy 拙作パッチの iconv化。
処理の最適化が完了していないけれども、 ようやく実地運用可能な段階までは完成したので、 ベンチマークを採ってみた。

53.039u 1.468s 0:54.71
53.148u 1.570s 0:54.95
53.523u 1.273s 0:55.07

anthy 拙作パッチの iconv化。
と言う訳で、バグとか機種依存になっていた部分とかを 治した／直したので、ベンチマークを採り直してみた。

35.085u 0.570s 0:35.79
35.015u 0.710s 0:35.82
36.195u 0.765s 0:37.06

Anthy の学習データ。

手元の Anthy では、 パラメータのチューニングに使う為に、 実地運用での学習データの利用状況を集積するため、 学習データの削除機能を無効にしてある。
で、 約21ヶ月ずっと溜め続けた結果、 学習データが 7.5MiB くら溜まっているのだが、 ここまで溜まっていると、もの凄く遅い。 学習データの再読込時にお茶を一口二口口に出来るくらい遅い。 いい加減、我慢の限度が。
学習データの利用効率の統計を取って、効果が低い部分は削除する事にした。 「Anthy 改造パッチの詳細解説と覚え書きと落書きとグチ - 継続使用の試験結果とかベンチマーク結果とか - Fri,12 Jun,2009」

延べ利用回数での利用効率から言うと、 PREFIX_HISTORY, SUFFIX_HISTORY, INDEP_HISTORY, DEP_HISTORY の４種類は９割を越える圧倒的な利用効率で、 CAND_HISTORY はちょっと落ちて７割だが、 実際の変換では CAND_HISTORY で救われる事が結構有り、 その事は利用効率の数字には出てこない。
そんなこんなで、この辺りは削除しない。

UNKNOWN_WORD の利用効率は４割だが、 先の nosuke氏のスパーギアの件みたいな事の対策としては外せない。
未知の単語は必ず全て単語登録するならば、 UNKNOWN_WORD は完全に不要になり、消しても構わないのだが。 一般利用者の事を考えると、それは無理だろう。

EXPANDPAIR は……、現状の学習の仕様だと、 無くてもいいとは思うのだけれども、 ビタビ絡みでどうなっているのかよく判っていないので、 迷う所。
UNKNOWN_WORD や OCHAIRE で同等の機能が効いている筈なのだが、 EXPANDPAIR を消しても 60KiB くらいの節約にしかならないし……。 消すか。

OCHAIRE ３文節は、部分を見ても全般を見ても、 利用効率が低い。 さらに、 OCHAIRE ２文節での代替も効いている筈。 時々、 OCHAIRE３文節であれば誤適用しないが OCHAIRE２文節だったので誤適用した、 と言う事も起きるけれども、効率悪すぎ。
削除する事にした。 これで１〜２割は削減できた。 思ったより減らないな。

OCHAIRE ２文節は、迷う所。 「末尾文節は自立語のみ取り出して付属語は削除して学習」 （wIwoD と woIwoD）にすると、 効率がグッと上がり５〜６割となるが、 付属語違いに対する誤適用がちょくちょく有り、 特に woIwoD はあからさまに誤適用が出てくるので、 一般利用者には勧めにくい。
そうなってくると、種別で削除するのはやめて、 時期で削除を考えてみる。 とすると、どうも、 最後に利用したのが直近３ヶ月以内である学習データの場合は 利用効率が平均を越えて３〜７割あり、 最後に利用したのがもっと古くなると２〜３割に落ちている。 何故かは不明だが、 取り敢えずこの辺りで切るのが良さそう。

DATA_SAMPLING は、現在は学習に利用しておらず、 実装する気も無い（実装が面倒）。 でも、見た感じ、 「前の文節の付属語 ＋ この文節の付属語」は 利用効率が圧倒的に高く７〜８割も有り OCHAIRE を確実に上回っている、 「前々文節の付属語 ＋ 前文節の付属語 ＋ この文節の付属語」と 「前の文節の自立語 ＋ この文節の付属語」は ４〜５割と OCHAIRE ２文節と同等の効率で、 「前の文節の自立語 ＋ この文節の自立語」でも ３〜４割と OCHAIRE ２文節に匹敵している。
学習として実装すると、 OCHAIRE よりも学習が適用できる率が高いもしくは匹敵するので、 案外いけるのかもしれない。 ただ、 OCHAIRE は文節の内容を丸ごと確保しているが、 こちらは文節の内容の特定部分だけなので、 誤適用とか不確実さとかは大きいかもしれない。

結局、 DATA_SAMPLING 全部と、OCHAIRE ３文節全部と、EXPANDPAIR 全部と、 OCHAIRE ２文節の古い物を削除で、 ６割削減して 3.6MiB くらいにまで縮まり、 だいぶ楽になった。 変換結果は、特段変化した感じはしない。 でも、やっぱりまだちょっと遅い。   速度面からは、 一般的には 1MiB くらいが妥当な所で、2MiB が上限、3MiB が限界かなぁ。 学習の効果を考えると、2〜5MiB は欲しいのだが。

Anthy の UCS/Unicode 対応。
文字のパース部分で対応している UCS/Unicode のバージョンは、 Unicode ver.2.1 もしくはそれ以前らしい。 CJK統合漢字拡張A や CJK統合漢字拡張B （JIS X 0213:2000 第３／４水準漢字）や CJK互換漢字 に 対応していなかった。
もっとも、たぶん、 逆変換の時に逆変換されずに素通りするかもしれない程度だけれども。 システム辞書に登録されている文字なら、 文字パースで対応していなくても、 変換すればそのまま素通りして出てくるし。

anthy 拙作パッチの iconv化。

iconv化前(-g3 -O0)
30.140u 0.601s 0:31.65
30.140u 0.562s 0:30.77
30.046u 0.554s 0:30.66
	1204K, 2848K

iconv化前(-g3 -O3)
21.242u 0.546s 0:21.84
21.265u 0.476s 0:21.76
21.070u 0.718s 0:21.82
	1064K, 2812K

iconv化後、xchar.c高速化前(-g3 -O0)
35.085u 0.632s 0:35.79
35.265u 0.679s 0:36.04
35.335u 0.710s 0:36.10
	1232K, 2988K

iconv化後、xchar.c高速化後(-g3 -O0)
33.085u 0.703s 0:33.87
33.171u 0.585s 0:33.86
33.250u 0.640s 0:33.96
	1456K, 3156K

iconv化後、xchar.c高速化後(-g3 -O3)
24.406u 0.679s 0:25.18
24.484u 0.703s 0:25.25
25.734u 0.648s 0:26.42
	1444K, 3192K

↑ 高速化を何パターンか試してみた。

iconv化前、-g3 -O0
29.945u 0.773s 0:30.80
30.085u 0.640s 0:30.82
30.289u 0.453s 0:30.80

iconv化後、-g3 -O0
35.125u 0.664s 0:35.86
35.429u 0.593s 0:36.11
34.882u 0.640s 0:35.63

iconv化後、xchar.c高速化後、-g3 -O0
33.062u 0.781s 0:33.92
33.890u 0.562s 0:34.53
33.242u 0.656s 0:34.02

iconv化後、xchar.c高速化後、iconv回りのバッファ統合後、-g3 -O0
32.898u 0.765s 0:33.75
32.984u 0.625s 0:33.72
33.046u 0.671s 0:33.83

iconv化後、xchar.c高速化後、iconv返値のstruct xstrまわりの統合後、-g3 -O0
28.882u 0.726s 0:29.71
29.203u 0.492s 0:29.79
29.171u 0.890s 0:30.11
28.882u 0.640s 0:29.59
	1260K 3160K

iconv化後、xchar.c高速化後、iconv回りのバッファ統合後、iconv返値のstruct xstrまわりの統合後、-g3 -O0
29.023u 0.742s 0:29.85
29.257u 0.585s 0:29.90
28.851u 0.656s 0:29.60



iconv化後、xchar.c高速化後、iconv回りのバッファ統合後、-g3 -O3
24.273u 0.828s 0:25.18
24.640u 0.648s 0:25.38
24.414u 0.757s 0:25.25

iconv化後、xchar.c高速化後、iconv回りのバッファ統合後、iconv返値のstruct xstrまわりの統合後、-g3 -O3
21.148u 0.562s 0:21.72
20.992u 0.687s 0:21.70
20.960u 0.820s 0:21.84

Anthy の iconv化。
EUC-JP を eucJP-MS から EUC-JP(JIS X 0208/0212) に 変更した事に合わせて、 辞書に EUC-JP で登録してあると文字コードを間違える恐れの有る 物を点検してみた。
……。 どう処置すべきなのか、悩ましい。 取り敢えず、 明確に間違っている物だけ消して utf8.t に移動してみた。
それとも、間違える可能性のある物は全て移動した方が良かったかな……。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」 の、anthy-9100h.mkworddic_fix.tar.bz2 。

Anthy 拙作パッチ。
こまごました不備の修正／調整が止まらなくなるジンクス。
とか書いた途端に止まるジンクス。
だがしかし、さらにそう書いた事で再発するジンクスもあるわけで。

Anthy 拙作パッチの悪相性。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」

「nosuke(のすけ)氏 - 日記みたいな何か - 2009年 6月18日 (木) - anthy-9100h.patch13Bptn23.iconv.2009617.alt-depgraph-090525」
> ./mkdepgraph ./indepword.txt ./master.depword .
> Anthy: iconv initialize failed.(EUC-JISX0213->internal)
> make[2]: *** [anthy.dep] セグメンテーション違反です
> make[2]: ディレクトリ `/home/compile/anthy-9100h.patch13Bptn23.iconv.2009617.alt-depgraph-090525/depgraph' から出ます
>
> ぬぅ，iconv -l しても JISX0213 系が出てこないな．

→ 原因
configure の時は GNU glibc版 iconv を使って EUC-JISX0213 が使用可能と判定し、 ビルドの時は GNU libiconv版 iconv を使って EUC-JISX0213 の初期化に失敗している。

→ 混ざった原因
configure.ac の判定処理と src-diclib/anthy_iconv.c の実装が 微妙に違っていて、その微妙な違いが原因で リンクするライブラリが変化していた。

→ 微妙に違う内容になった原因
GNU libiconv対応版を書き上げた後に、 GNU/Linux の GNU glibc版 iconv にも対応する様に 修正していったが、その際に片方だけ修正して もう片方の修正を忘れた。

→ 対処
configure.ac の判定処理と src-diclib/anthy_iconv.c の実装を 一致させた。

↑ anthy のパッチ。 そして再発するジンクス。
「nosuke氏 - 日記みたいな何か - 2009年 6月18日 (木) - anthy-9100h.patch13Bptn23.iconv.2009617.alt-depgraph-090525」。

その１。
iconv の初期化に失敗した時のエラー処理を 書きかけのまま忘れていました。 本来の予定では、 そこは SIGSEGV ではなくて普通にエラー終了になるはずでした。

その２。
英文の内容が間違っているし。 正： iconv initialization failed.

その３。
そもそも、標準設定でビルドした時には そのエラーが出ない様にした筈だった……。
原因：
configure の時は GNU glibc版 iconv を使って EUC-JISX0213 が使用可能と判定し、 ビルドの時は GNU libiconv版 iconv を使って EUC-JISX0213 の初期化に失敗。
単純に、 configure での判定処理からの iconv 呼び出しと、 ソースコード本体での iconv 呼び出しで、 記述がずれていて、違うライブラリを呼び出してしまうポカミス。

その４。
その３の状況を故意に作り出す為に複数の libiconv をインストールして configure --with-libiconv-prefix でどれを使うのかを 変化させようとしたら、 --with-libiconv-prefix オプションの処理が不完全で 使い分けがうまくできなかったポカミスを発見。

「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」、 その辺の処理を修正した patch13Bptn23.iconv.2009619版に更新。
2009617版の、 OS近辺の環境設定の検出を修正しただけで本体部分は変わっていないので、 2009617版で問題無く動いているならば、 更新する必要は無し。
patch13Bptn23 なパッチと iconv なパッチは 直交している（その気になれば iconv化だけのパッチも作れる）ので、 ズラズラと書いたけれども、 リビジョン名を考えるのが面倒になっただけとも言う。

しかもパッチのファイルへのリンクを張り間違えて ダウンロード出来無くなっていたし。 なんかもうボロボロ。

「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
取り敢えず、 patch13Bptn23.iconv.2009619版にて、 既知の問題やトラブルやバグは潰し終わったと思うけれど。

↑ とか書いた途端に AUTHORS.patch に書き忘れが見つかる……。

「vagus氏 - 丘の道を登り - 2009年04月13日 - 「未完成らしい」他 【追記】4/13」、 「動詞連用形について複合語を作る接尾語の D2T?? という品詞コード」の話。
「vagus氏 - 丘の道を登り - 2009年04月15日 - D2T35 を有効にする方法」、 D2T35 を有効にする方法。
「vagus氏 - 丘の道を登り - 2009年05月05日 - 自作 depgraph 更新(5/4) - 出し直し(5/6)」、 D2T35 を再有効化。
「nosuke(のすけ)氏 - 日記みたいな何か - 2009年 6月23日 (火) - 最近のAnthy」、 「いがいと」で「い甲斐と」が出る話。
Wed,24 Jun,2009 〜 Fri,26 Jun,2009の追記(Sun,28 Jun,2009) まで、延々長引きます。

分析：
構造としては、
「（動詞の連用形）」 + 「がい #D2T35*21 甲斐」 + 「（付属語）と」
で、「働き甲斐と」や「生き甲斐と」などの延長の形。

この場合、 「（動詞の連用形）」の部分に「い」が当てはめられているけれども、 これは、 「#KS*400 居」「#KS*200 射」「#KS*50 鋳」 などの平仮名表記である「#KS*600 い」が、
上下一段活用動詞語幹| H SyCy :0.0 @_上下一段語幹後 "" @上下一段連用形 "" @_上下一段連用形(共通) "" SyCy@
と付属語グラフが適用されて動詞連用形になった物。


「いがいと」に当てはまるそれ以外の候補は、
「いがい #T07*300 意外 #T35*300 以外 #T35*200 遺骸」
「いがいと #F14*400 意外と」
などがある。

「意外と」は 400ポイント？、
「い甲斐と」の「#KS*600 い」が 600ポイント？だけれども 付属語付きなので減点して 300ポイント？、
他の候補が 300〜200ポイント？だけれども 付属語付きなので減点して 150〜100ポイント？、
全部まとめるとスコア？の高い順に、
「意外と」(400)、「い甲斐と」(300)、（中略）、「以外と」(150)、（以下略）
になる。


……。
D2T35 や N2T35 は、スコア？評価にて、 先頭の動詞等のスコア？をそのまま用いずに減点した方が良いのかも……。

以下、スコアと並び順の生データ。

コーパス無し：
いがいと(
	意外と:(1,1000,YM,6553,Se,E:0,F:400,LF:0,D:0,L:0)82,118 ,
	い甲斐と:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)63,617 ,
	いがいと:(N,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)63,515 ,
	居甲斐と:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)43,142 ,
	居がいと:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)43,040 ,
	以外と:(,1000,Nk,3276,Sk,E:0,F:300,LF:0,D:1,L:1)30,665 ,
	射甲斐と:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)22,667 ,
	射がいと:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)22,565 ,
	遺骸と:(,1000,Nk,3276,Sk,E:0,F:300,LF:0,D:1,L:1)20,428 ,
	鋳甲斐と:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)7,311 ,
	鋳がいと:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)7,209 ,
	イガイト:(N,0,-)2 ,
	イガイと:(g,0,-)2 ,
):

コーパス有り：
いがいと(
	意外と:(1,1000,YM,69579,Sy,E:0,F:400,LF:0,D:0,L:0)871,912 ,
	以外と:(,1000,Nk,67236,Sk,E:0,F:300,LF:0,D:1,L:1)632,289 ,
	遺骸と:(,1000,Nk,67236,Sk,E:0,F:300,LF:0,D:1,L:1)422,177 ,
	い甲斐と:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)63,617 ,
	いがいと:(N,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)63,515 ,
	居甲斐と:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)43,142 ,
	居がいと:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)43,040 ,
	射甲斐と:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)22,667 ,
	射がいと:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)22,565 ,
	鋳甲斐と:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)7,311 ,
	鋳がいと:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)7,209 ,
	イガイト:(N,0,-)2 ,
	イガイと:(g,0,-)2 ,
):

anthy の拙作パッチの patch11以降の全てに於いて、 amd64(EM64T), sparc64 などで、 コーパスの検索子？の生成をミスっているバグ発見（泣。 たぶん MIPS64, PowerPC G5, IA-64 にもあてはまる。
mergesort() に入力できる配列は、 １要素のサイズが sizeof(void*)/2 以上のもの限定らしい。 が、見事に見落としていた。
コーパスの検索子？は、 ソートしておかないとコーパスの検索に失敗する事が多くなる。 のだが、 検索子？は short型の配列なので、 そのまま mergesort() してしまうと、 amd64 や sparc64 などの場合は sizeof(short) は sizeof(void*)/2 より小さいので、 mergesort() に蹴られてソートできない。 全然気付いていなかった。
FreeBSD/amd64 や OpenBSD/amd64 では、 コーパス由来と憶測される変な変換が出なかったのは、 そのせいだったのか orz。

原作版 anthy のバグ。
コーパスにて、 単語辞書に載っていない単語だか、 より短い単語が単語辞書に載っている単語だか、 を使うと、make update_params で無限ループになっている。
原作版anthy-9100h + alt-depgraph-090525 にて発症する事を確認済。
具体例：
原作版anthy-9100h + alt-depgraph-090525 にて、 corpus.1.txt の |ほぞんじょうたいの|わるい|しゃしんしか|のこってない| |保存状態の|悪い|写真しか|残ってない| を処理しようとして、 まず「ほぞんじょうたいの」の部分を作ろうとする。
最初に「ほぞん」が候補として提示され、 目的の文節より短いので文節長を伸ばして「ほぞんじ」。
まだ短いので文節長を伸ばして「ほぞんじょ」になるが、 「ほぞんじょ」は 「ほぞん」「じ」「ょ」を自動で組み合わせて作った MW_WRAP なので、 最初の単語「ほぞん」を候補として提示する。
目的の文節より短いので文節長を伸ばして「ほぞんじ」。
以下無限ループ。 対処法：その１：
word_split_info_cache の seg_border[] の仕様を変更し、 src-splitter/metaword.c の anthy_mark_border_by_metaword() を 再設計して丸ごと書き直す。
対処法：その２：
バグを発症させる単語を、コーパスで使わない。
備考：
原作版の仕様変更となる本家送付用のパッチの作成は、気が進まない。 ので、特に支障が無ければ対処法その２でテキトーにやって下さい。

原作版 anthy の潜在バグで、 かつ、拙作パッチの iconv対応版で顕在化するバグ。
make update_params で使っている calctrans にて、 src-diclib/ 関連の初期化をしないまま、処理を行っている。 その為、 拙作 iconv対応版にて iconv の初期化をしないまま iconv を使ってしまい、 SIGSEGV を起こす。
このバグ、mkdepgraph にも当てはまる。

備考：
原作版だと潜在化したままで問題にならないので、 本家送付用パッチを作る気にならない。

「いがいと」の続き。
↑*3,2,1 を治すついでに、 「動詞連用形＋名詞／形容詞」でのスコアを、 「動詞連用形」のスコアから「名詞／形容詞」に変更してみた。
連用形に付加する為の「名詞／形容詞」のスコアは小さく抑えてあるので、 実質的には、文節の総合スコアも下がる筈。
元に戻したいならば、 CANDIDATE_RENYOU_SCORE_LASTWORD false にて、 「動詞連用形」のスコアを用いた計算に戻る。
「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
ジンクス発動しまくりで毎日更新状態。
Thu,25 Jun,2009追記：
↑だとあまりうまくないので、計算方法を変更。

↑*2,1 「いがいと」、昨日の続き。
Wed,24 Jun,2009 〜 Fri,26 Jun,2009の追記(Sun,28 Jun,2009) まで、延々長引きます。

単純に 「名詞／形容詞」のスコアだけだとか、 「動詞連用形」のスコアだけだとかにすると、 どうも並び順がうまくない気がする。
ので、 相乗平均に変えてみる。 相加平均だと、スコアが大きすぎる事が判っているのでやらない。

↑ と言うわけで、 D2T?? の動詞連用形の場合の文節スコアを、
CANDIDATE_RENYOU_SCORE_FIRSTWORD、動詞部分のスコアを利用
CANDIDATE_RENYOU_SCORE_LASTWORD、名詞／形容詞部分のスコアを利用
CANDIDATE_RENYOU_SCORE_GEOMETRICMEAN、双方の相乗平均を利用
に変更。

「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
ジンクス発動しまくりで毎日更新状態。

相乗平均にしてコーパス無し：
いがいと(
	意外と:(1,1000,YM,6553,Se,E:0,F:400,LF:0,D:0,L:0)82,118 ,
	以外と:(,1000,Nk,3276,Sk,E:0,F:300,LF:0,D:1,L:1)30,665 ,
	遺骸と:(,1000,Nk,3276,Sk,E:0,F:300,LF:0,D:1,L:1)20,428 ,
	い甲斐と:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)11,790 ,
	いがいと:(N,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)11,790 ,
	居甲斐と:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)9,691 ,
	居がいと:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)9,679 ,
	射甲斐と:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)6,991 ,
	射がいと:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)6,978 ,
	鋳甲斐と:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)3,933 ,
	鋳がいと:(,1000,Ne,3276,S-,E:0,F:21,LF:0,D:1,L:1)3,907 ,
	イガイト:(N,0,-)2 ,
	イガイと:(g,0,-)2 ,
):

まあこんなもんでしょう。
＃ D2T?? は、
＃ 多少変な候補は出る事は有っても、
＃ まともな候補が出る効果もあるし、
＃ 上記の様にパラメータチューニングで変な候補が目立たなくなったし、
＃ 変な候補が出ても学習でカバーできるし、
＃ なので、寛容派。

anthy-9100h + alt-depgraph-090525 謎の現象。
後で振り返ってみれば、「いがいと」の続きの話だった。 Wed,24 Jun,2009 〜 Fri,26 Jun,2009の追記(Sun,28 Jun,2009) まで、延々長引きます。
よみがなに「っ」や「ぱ」を含んでいる D2T35 が無視される……。

っぱなし #D2T35*20 っぱなし っ放し
っはなし #D2T35*20 っぱなし っ放し
ぱっなし #D2T35*20 っぱなし っ放し
はっなし #D2T35*20 っぱなし っ放し
ぱなし #D2T35*20 っぱなし っ放し
はなし #D2T35*20 っぱなし っ放し

とあった時、 「いはなし」だけ「居っ放し」の様に D2T35 が働くが、 その他は「居」に「っ放し」が付いてくれない。
原作版でも拙作パッチ版でもどちらでも変わらず。

#D2T35 で使う読み仮名と 同じ読み仮名の候補 （品詞は D2T35 や N2T35 以外なら何でも良い）が無いと、 #D2T35 は無視されるらしい。
試しに「っぱなし #KJ ×」とか言うエントリを作ってやったら、 「いっぱなし」で「居っ放し」が出る様になった。

……。
src-worddic/wtab.h にて WF_INDEP 指定されている品詞に関して、 src-splitter/wordlist.c の anthy_make_word_list_all() で wordlist を生成し、 生成された wordlist に付属語を付加して metaword を生成し、 生成された metaword 同士を連結して 「動詞連用形 + 形容詞化接尾語」(D2KY, yasui) や 「動詞連用形 + 名詞化接尾語」(D2T16, D2T35) など を生成するらしい。
従って、連用形の元になる品詞（動詞と D2KY,yasui,D2T16,D2T35）は WF_INDEP 指定されていないといけないらしい。
これ、以前、私が vagus氏に余計な事言った所かも…… ＯＲＺ。

「っぱなし #KJ ×」みたいな余計なエントリを作ると解消される理由。
wordlist を生成する時、 同じ読み仮名のエントリは縮退して１つにまとめられるので、 同じ読み仮名の候補の内、 どれか一つの品詞が WF_INDEP を持っていれば wordlist は生成されるから。   「っぱなし #D2T35*20 っ放し」にて「っぱなし」が WF_NONE でも、 「っぱなし #KJ ×」にて「っぱなし」が WF_INDEP になっていて、 WF_INDEP が実行される。

↑ そして 「|つけ|っぱなし|」と２文節に分割する事を学習した状態や、 付属語の切る位置を変更したりすると、 「点けっ放し」（つけっぱなし）や「付けっ放し」（つけっぱなし）が 生成されないオチ。
文節区切り位置の指定をして１文節で変換させようとすると、 連用形の元になる候補（動詞と D2KY,yasui,D2T16,D2T35）の段階で metaword が使用不可判定（理由：指定された文節長より短い）されてしまい、 連結した metaword も使用不可判定 （理由：構成している metaword が使用不可判定されている） されてしまうらしい。

「かな漢字変換 anthy で、個人用学習データを活用して変換結果の改善を目指すパッチ」
ジンクス発動しまくりで毎日更新状態。
anthy_lookup_half_wide() の返値を間違えていた事に気付いたので修正。
オプション DONOT_LEARN_EXCEPTION_WORD_AT_* にて、 よみがなと変換結果を取り違えていたので修正。
あと「っぱなし」の件をなんとかしてみた。 ……原作版 anthy だと同じ問題が出るかも、どうしよう。

↑ Sun,28 Jun,2009 追記：
後で振り返ってみれば、「いがいと」の続きの話だった。 Wed,24 Jun,2009 〜 Fri,26 Jun,2009の追記(Sun,28 Jun,2009) まで、延々長引きます。

原作版 anthy-9100h + alt-depgraph-090525 でも 全く同じ問題が発症する事を確認。

まず学習が無い状態で「つけっぱなし」を変換すると、 「付けっ放し」とか「着けっ放し」とかが、 ちゃんと候補に出る。
そこで、 「|点け|っ放し|」と２文節に分割して変換して確定し、学習させる （純粋に原作版のままだと、「点け」が２文字の文節なので、 学習が拒絶されるかも。 たしか原作版だと、学習量の節約の為（コメントにそんな感じの事が）に、 文節長が２だったか３だったか以下だと学習を拒絶した様な気が）。
再び「つけっぱなし」を変換すると、 「|点け|っ放し|」が候補に出てくるので、 「|つけっぱなし|」で１文節になる様に文節区切り位置を変更すると、 「つけっぱなし」と「ツケッパナシ」しか候補に出てこない。

対処法としては、 src-splitter/evalborder.c の metaword_constraint_check()、 case MW_CHECK_BORDER: と case MW_CHECK_WRAP: にて、 mw->can_use に ok や ng を入れている部分の判定方法を、 metaword_constraint_check() の再帰呼び出し結果を用いず、 border_check(mw, from, border) の結果だけで判定する様に 変えれば良いと思う。

こんな感じ。
--- anthy-9100h.org/src-splitter/evalborder.c	Thu Apr 19 08:29:41 2007
+++ anthy-9100h.org.alt-depgraph-090525.test/src-splitter/evalborder.c	Tue Jun 30 23:36:44 2009
@@ -64,16 +64,24 @@ metaword_constraint_check(struct splitter_context *sc,
       if (mw2)
 	metaword_constraint_check(sc, mw2, mw2->from, border);
       
+     #if 0
       if ((!mw1 || mw1->can_use == ok) && (!mw2 || mw2->can_use == ok)) {
 	mw->can_use = ok;
       } else {
 	mw->can_use = ng;
       }
+     #else
+      mw->can_use = border_check(mw, from, border) ? ok : ng;
+     #endif
     }
     break;
   case MW_CHECK_WRAP:
     metaword_constraint_check(sc, mw->mw1, from, border);
+   #if 0
     mw->can_use = mw->mw1->can_use;
+   #else
+    mw->can_use = border_check(mw, from, border) ? ok : ng;
+   #endif
     break;
   case MW_CHECK_NUMBER:
     {

• D2KY,yasui,D2T16,D2T35 などは、 WF_INDEP にしないと候補が生成されない事がある。
• 文節区切りの位置を手動で指定／変更すると、 D2KY,yasui,D2T16,D2T35 などの候補が生成されない事がある。

anthy 「こんど」。
「こんどこそ」で変換したら、「今渡こそ」が第１候補だった。
学習データを確認してみたら、 以前、誤変換して誤学習したのを、 今までずっと気付かないでいたらしい。 ちなみに、「今渡」（こんど）は人名らしい。
この手の誤変換を防ぐには、どうしたらいいのだろう……。 どうしようもないか……。
理想論？としては、 ToolTip で品詞を表示するとか、なんだろうけれど……。 フロントエンドのソフトの仕様変更とか大幅改造とかが必須になるしなぁ。