Anthy 改造パッチの詳細解説と覚え書きと落書きとグチの物置小屋

……バッドノウハウのカタマリかもしれん。

以下の内容は、仮定と推測に基づいた憶測が混じっており、 事実と異なる、あるいは事実に反する記述である可能性があります。 また、事実誤認や誤解が無い事を保証するものではありません。

本ページの著作権は、私 fenix.ne.jp の G-HAL に属します。 Copyright(C)2007-2011 G-HAL.


複数の Anthy version/variant を試す時の注意：

Anthy の複数の version/variant を試す場合、 各々の version/variant にて configure する時に、 --prefix オプションでインストール先を別に指定して make install まで行い、 実行時に
env LD_LIBRARY_PATH=（インストール先）/lib （テストプログラム）
とかしないと、 違う version/variant のライブラリとか辞書とかを使ってしまいます。
＃ LD_LIBRARY_PATH に指定するパスの記述では、 ホームディレクトリの指定に ~ が使えない場合があるので注意。
また、Anthy の Makefile はアレなので？、 ファイルを書き換えて make しても更新されない場合が有ります。
make clean してから make install すれば、ほぼ確実に更新される筈です。


patch0 の解説：

個人用学習データが１万件くらい貯まってくると、 個人用学習データだけでそこそこ良い変換をする様になってくるので、 システム埋め込みのコーパスの必要性が薄れてきます。 なので、思い切ってシステム埋め込みのコーパスを全て削除するパッチ。

悪い方の副作用として、 個人用学習データがまだ十分に貯まっていない時にこれを使うと、 変換結果が若干悪くなるかもしれません。 また、まだ学習されていない様な内容の変換を行った時に、 変換結果が悪くなる場合があります。

良い方の副作用として、 変換の候補がコーパスの文体や癖の影響を受けなくなります。


patch無印 の解説：

このパッチを使うと、学習量の上限が、 取り敢えず１年〜２年くらい学習を続けても 上限超過で削除されたりしない程度の量になります。

副作用として、 辞書（last-record1_default）が肥大化し、 初動の変換に必要な時間が増えます （メモリ上に展開されたキャッシュにヒットすれば速いのですが）。 半年間学習し続けると、 とても「あの軽快だった Anthy」とは思えない程、遅くなります。


patch1 の解説：

patch無印と alt-cannadic の誤字修正パッチをマージした物です。


patch2 の解説：

誤学習をしない様にする為と、個人用学習データの肥大化を防ぐ為、 あとついでに無駄なディスク書き込みを減らす為、 変換途中のまだ間違っている変換内容を学習しない様にしました。

また、コマンドラインツール anthy-agent に、 辞書のフラッシュ （last-record2_default から last-record1_default への移行） 機能を追加しました。

% anthy-agent --update-base-record --do-nothing

とする事で、フラッシュします。

原作版では変換途中に OCHAIRE, CAND_HISTORY, INDEPPAIR の学習を更新していますが、 学習データーベースを変換バッファに使っているだけで、 実際の学習は、されていない模様。


patch3 の解説：

個人用学習データの肥大化を防ぐ為と、不要な学習を行わない様にする為、 特定の記号を含む項目を OCHAIRE 学習しない様にしました。

具体的には、句読点や括弧類や記号の文節区切りを学習しません。 日本語の文書ならば句読点や括弧類や記号は必ず文節区切りになるので、 学習する必要無いし。

その類の文節区切りも学習させたい場合は、 src-ordering/exception_word_list.c の exception_word_list_cstr[] から、 学習させたい物を消して下さい。

また、学習データをとことん集積する為に、 OCHAIREの学習削除の学習を行わない様にしました。 但しこれには副作用があって、 文節を切る様に学習させた内容に対して、 文節を切らずに１文節で変換する様に学習させる事ができなくなります （この問題は、patch12 で解消…… と言うよりも、patch12 になるまで問題に気付かなかった）。


patch4 の解説：

オリジナル版の Anthy に、 不正なメモリアクセスを行うバグを３件見つけたので修正しました。

OSDN のプロジェクト/トラッカー: Anthy/バグの、 ID:12379「src-util/dic-tool.c の英文タイプミス」 （IWAI Masaharu 氏、2008-04-21 07:16） パッチをマージ。

学習結果を最後に利用した日付と利用した回数でスコアリングし、 学習結果の削除を行う際にスコアリングの低い物から削除する様に変更しました。 これにより、 最近の変換だけでなく、 利用頻度の高い変換の学習も保持される様になります。 スコアリングは last-record1_* のファイルサイズが大きくなった場合のみ 行う様にしてあるので、普段の負荷は変わらない筈です。

CAND_HISTORY の学習と削除は、 過去８種類の同読みの変換からスコアリングで順位を決める様に変更しました。 これにより、 利用頻度が２番目以降の変換も候補の２〜８番目に残る様になりました。

補足： 基本的な方針として、 変換結果は時間不変である（同じ条件ならば、いつも同じ結果になる） べき、だと考えています。 しかしながら、スコアリングに相対時刻を用いると、 時間不変では無くなってしまいます （処理を行った時刻によって結果が変わってしまう）が、 本パッチでスコアリングに相対時刻を用いるトリガは、 CAND_HISTORY の場合は第１候補を変更した時のみ、 学習全般の枝刈りの場合は変換確定（学習データ更新）した時に 古い物に対してのみ、 であり、 （CAND_HISTORY の場合は） 利用者にも変化が起こる事が明示的かつ合理的に認識・判断できる （付け加えて、第１候補だけはスコアリングを行わずに、 利用者が指定した物を第１候補としている）、 （学習全般の枝刈りの場合は） どのみち状態の変化を行わなければならないし 枝刈りで残す量がある程度大きければスコアリングの影響は小さい、 ので、 不変性を維持しなくても問題にはならない、と考えたからです。

＃ 原作の anthy では、 学習結果の削除はデータベースの後方にある物から削除するので、 利用頻度が高くても、 暫く使っていなかった変換結果の学習は消される事があります。 また、 CAND_HISTORY と EXPANDPAIR の同読みの学習は、 過去８回の変換で使った物のみ、となっているので、 学習が１種類しか残らずに 利用頻度が２番目やそれ以降の物が候補に出てこない事があります。

なお、EXPANDPAIR の学習結果のスコアリングは、 初回学習時以降、全くと言っていいほど変わりません。 これは OCHAIRE 学習結果が EXPANDPAIR の学習結果よりも優先して使われ、 その結果 EXPANDPAIR の学習結果が全く利用されていない為です。

注意：

patch4では、学習結果のデータ形式が変更になっています。 原作の anthy 及び patch〜patch3 までで学習した内容は patch4 でもそのまま利用できますが、 patch4 以降で学習した内容は原作及び patch〜patch3 では利用できません。


patch5 の解説：

オリジナル版の Anthy に、 メモリを明示的に初期化せずに使っている部分を また見つけたので修正しました。 C99 では、 .bss な静的変数の初期値は 0(+0.0) と定義されているらしい、 ので、仕様上は問題無い、 ……実際の実装の話になると問題になるケースも有る。

学習データの読み込みバッファを多めに確保する事で メモリ割当サイズ変更の回数を減らし、高速化しました。

副作用として、 無駄なメモリが増える、 valgrind等の不正なメモリアクセスの検出ツールでの検査が甘くなる、 があります。

プロファイラで追跡したり実際に計測した所では２割程度速くなりましたが、 実感としては、あまり変わっていない様に思えます。

注意：個人用学習データの形式が（以下略）


patch6 の解説：

オリジナルの Anthy だと、文節の切り直しを行なって再変換した場合、 文全体の再評価を行う為、注目文節より左側の変換結果が変わる事があります。 このパッチでは、 注目文節より左側は再変換を行っても再評価しない様に、変更します。

注意：個人用学習データの形式が（以下略）


patch7 の解説：

個人用学習データのファイルのパーミッションを、 group と other が読めない物に変更しました。

個人用学習データをバイナリ形式に変換して、 読み込みを約７割高速化しました ……本当か？測定結果間違ってないか？。

バイナリ形式の学習データのファイル名は、 「（学習データの基本ファイル名）.bin」 です。

バイナリ形式の学習データのデータ形式は、 アーキテクチャや OS に非依存の形式にしてあります。 i386系と amd64系での共用は動作確認済。 設計上は、 sparc だろうが alpha だろうが MIPS だろうが PowerPC だろうが ARM だろうが m68k だろうが SH だろうが M32 だろうが、 何でも共用できる筈です（実機が無い為、未確認）。

学習データの保存を行う際には、 従来通りのテキスト形式と、新規に追加したバイナリ形式の、 両方で保存します （テキスト形式でも保存しておかないと、 テキストエディタを使った誤学習の修正作業ができないし、 学習の追加／変更／削除の比較ができないから。 加えて、何らかの再利用をする場合は、テキスト形式の方が有利だから）。

従来通り、 テキスト形式の学習データが変更された場合のみ、 学習データの再読み込みを行います。 バイナリ形式の学習データのみが変更された場合、 再読み込みは行いません。

学習データの再読み込みを行う際は、 バイナリ形式のデータがあればそれを読み込みます。 無い場合は従来通りテキスト形式から読み込みます。

学習データを手作業で修正する場合、 テキスト形式の学習データを編集すると共に、 バイナリ形式の学習データを削除して下さい。

注意１：個人用学習データの形式が（以下略）

注意２：本パッチ中の src-diclib/strlcpy.c と src-diclib/strlcat.c は BSDライセンスになります。


patch8 の解説：

オリジナル版の Anthy のデータベース処理にバグ？を見つけたので 修正してみました （do_select_row() から trie_insert() を呼び出した時に PROTECT フラグを破壊した後に PROTECTフラグを見ているので、 意味が無かった）。 ただ、修正しても意味は無さそうです。

オリジナルの Anthy に、 複数のアプリケーションで同時にかな漢字変換を行った場合に 学習データが過去に戻るバグ？仕様？を見つけたので、 それを発症しにくくする修正をしました。 但しあくまで発症しにくくしただけで完全な治療はしていません。 ロックの仕様を変更して大幅改変しないと根治できないので治しません。

オリジナル版の Anthy に、 last-record2_* の構文チェックが甘い部分が有ったので修正してみました。

学習のセクションの識別子の処理方法を文字列から enum に変更し、 セクション毎のヒント情報を持てる様にした。

メモリ先行確保量のヒント情報を持つ事で、数％〜１割程度の高速化。

個人の学習データの保管や作業ファイルを置くディレクトリを、 環境変数 ANTHY_CONFDIR で変更可能にした。 但し、指定ディレクトリの正当性の検査は行っていませんので、 注意して下さい。 また、ANTHY_CONFDIR で指定するディレクトリは、 ${HOME} 下からの相対ディレクトリとなります。

ついでに、各種環境設定の一部を集約して変更可能にした。 但し、そうそう頻繁に変更する物でもなく、また面倒なので、 動的変更用の API を作る気はありません。 変更したい場合は src-worddic/settings.c を変更して、 anthy ライブラリの再構築を行なって下さい。 anthy ライブラリの再構築を行わずに動的に変更したい場合、 src-worddic/settings.c を変更して 単独で shared library形式でコンパイルし、 LD_PRELOAD してください （patch13 にて ${HOME}/.anthy/conf で指定できるように変更しました。 再構築の必要はありません）。

さらについでに勢いで、 オリジナルの Anthy でキャストのウォーニングが大量に出るのを、 全部叩き潰した。

Anthy の置き換えとなる かな漢字変換 の開発が 次世代アーキテクチャの計算機／ＯＳの 一般化に間に合わなかった場合の保険として、 int型が 64bit なシステムだと メモリ破壊かスタック破壊を起こす可能性があるバグ？仕様？を修正。 （int型を数字に変換した時の最大文字数が 10文字固定になっていた） （2286年11月21日以降か、 変換候補数／文節数／候補の頻度値のどれかが 9999999999個を越えた場合か、 変換候補数／文節数／候補の頻度値のどれかが -999999999個より小さくなった場合に、 発症する）

注意１：個人用学習データの形式が（以下略）

注意２：本パッチ中の src-diclib/strlcpy.c と src-diclib/strlcat.c は BSDライセンスになります。


patch9 の解説：

Anthy の置き換えとなる かな漢字変換 の開発が 2038年までに間に合わなかった場合の保険として、 2038年問題対応。 （time_t と int が相互変換可能である前提になっていた） 但し、2038年問題が発症しても、 候補の並び順の学習結果が破壊され、 並び順が出鱈目になる程度だと思われます。

2038年問題対応と言っても、 OS側が2038年問題非対応の場合は効果がありません。

メモリのアラインメントを間違える可能性の有るバグ？仕様？ 正しいアラインメントよりも整数倍大きい値に間違えるだけなので、問題無し。 を、一応修正。

無駄そうな部分を調整してみたけれど、速度は変わらなかった。

注意１：

patch9では、再度、学習結果のデータ形式が変更になっています。 原作の anthy 及び patch〜patch8 までで学習した内容は patch9 でもそのまま利用できますが、 patch9 で学習した内容は原作及び patch〜patch8 では利用できません。

注意２：本パッチ中の src-diclib/strlcpy.c と src-diclib/strlcat.c は BSDライセンスになります。


patch10 の解説：

変換候補の学習(CAND_HISTORY)と予測変換の学習(PREDICTION)を統合する事で、 個人用学習データの大きさを１割程度削減しました。 それにより読み込みが１割程度速くなった筈ですが、 体感では変わった気がしません。

オリジナルの Anthy もしくは patch9 までの Anthy から 本 patch10 に移行する場合、 予測変換の学習データを従来の形式から新しい形式に変換する必要があります。

% rm ~/.anthy/last-record1_*.bin
% anthy-agent --do-nothing --update-base-record
% rm ~/.anthy/last-record1_*.bin
% anthy-agent --do-nothing --update-base-record

とする事で、変換が行われます （１回目の anthy-agent にて last-record2_* を last-record1_* へマージ。 ２回目の anthy-agent にて テキスト形式から読み込む事で PREDICTION を CAND_HISTORY へ統合）。

注意１：

予測変換を利用している人の場合、 予測変換の変換の傾向が変わる可能性があります。 予測変換を利用していない人の場合、デメリットはありません。

注意２：

本 patch10 適用後に学習した予測変換の学習データは patch9 までの Anthy では利用できなくなり、 予測変換の学習データが全く無い状態と同じになります。

注意３：本パッチ中の src-diclib/strlcpy.c と src-diclib/strlcat.c は BSDライセンスになります。


patch11 の解説：

オリジナルの Anthy に、 郵便番号辞書を使う変換をした時にメモリリークしているのを見つけたので 修正。

オリジナルの Anthy に、 libc 側で NULLポインタの検査をしている事を前提としている箇所 （qsort() の base に NULL 突っ込んでる）を１つ見つけたので修正。

数値や記号やひらがなやカタカナだけの文節は、 学習しているとキリが無さそうなので、 学習しない様に変更。 「２割」で１文節にして変換すると、学習します。 「２」＋「割」と数値だけの文節にして変換すると、学習しません。 この方法は大量の文を入力する時に面倒なので、patch12 以降は廃止しました。 patch11 のみで有効な方法です。

似た様な内容を変換した時に、あるいは全く同じ内容を変換した時に、 頻度情報も同値で、 学習状況もほとんど同じで、 デバッガで追跡してみると候補の最終評価値まで全く同じなのに、 候補の並び順が変わっている事が有って気になっていた （急いで文書を打たないといけない時に、 さっき変換した時と違う物が出てきて、気を取られて困った）。

それから、数値を変換した時の候補の並び順が、 学習していないにも関わらず、 入力した数値によって違っている事が気になっていた。

例： 学習や単語登録がされていない場合、 「１２３」を変換すると

となるが、「１２３４」だと

になるし、「１」だと

になる。

調べてみたら、 候補の並び順のソートにクイックソートを使っているので 計算機のアーキテクチャやら OS やら接頭辞／接尾辞の有無やら 変換する数値やら運やらによって並び順が変わる、 数値だけの文節に対して ひらがなフラグとカタカナフラグの 両方が立っていて処理が変になっている、 「１」〜「５０」はシステム辞書での評価がそう設定してあるだけだった、 だった。

上記の例の様に、数値や記号を変換する時や、 同じ評価値を持つ候補がある時に、 候補の並び順が安定する（毎回同じになる）様に修正した。

システム辞書もしくはユーザ辞書で単語登録されていない限り、 下記の順で固定します。 変更したい場合は、src-worddic/settings.c の .extra_flag の CEF_TUNESCORE_SIGN にて設定して下さい （patch12以降では ${HOME}/.anthy/conf にて指定）。

「１」〜「５０」はシステム辞書での単語登録で優先順位が指定されている為、 プログラム側で順序を変えるのは不可能です （ alt-cannadic/gcannaf.ctd で、 ASCII数字(#NN*22) ＞ JIS X 0208 数字(#NN*21) ＞ 漢数字(#NN*20)、 で登録されている。 システム辞書の頻度値は ユーザ辞書の頻度値の10倍くらいの強さを持っているらしい） 。 ユーザ辞書に「０」〜「５０」（読み、書き方、ともに、いわゆる全角）を 頻度 300 くらいで単語登録する事で、並び順を優先させる事ができます。 なお、 private_words_default は１行に１項目しか記述できないので注意。


……パッチが 11 まで来るとは思わなかった。 4 とかせいぜい 6 で終わると思っていたのに。


patch12 の解説：

オリジナルの Anthy では、 学習の蓄積や、学習結果の変換への反映に関しては、 かなり軽視している（それともコーパス導入で不要になったと考えた？） 傾向がある様な気がします（根拠無し）。

本 patch12/patch13 シリーズでは、 その学習に関して改善あるいは強化してみようと試みるものです。

但し、 理論的裏付けをしないままに直感と思い付きでやった為、 何が起こるかは判りません。

追加機能や変更した機能のパラメータチューニングに関しては、 sample/conf を参照されたし。

オリジナルの Anthy では、 文節区切りには OCHAIRE学習のみ反映し、 優先順位は 「システム辞書から生成した文節区切りと OCHAIRE から生成した文節区切りでは OCHAIRE が優先、 OCHAIRE同士ならシステム辞書の設定値で判定、 非OCHAIRE同士もシステム辞書の設定値で判定」 となっています。 また、 文節の候補の並び順には CAND_HISTORY学習のみ反映し、 候補の優先順位は CAND_HISTORYで学習した通り、となっています。

この方法の場合、 文節の切り方に対して システム辞書（システム持ちのコーパスを含む）の内容を反映する という点では安定しますが、 単文節変換での区切り位置の学習（区切りが無いという学習）が 全くできなかったり（注意：patch3 にて、 頻繁に OCHAIRE学習データを消すのを避ける様にした結果、そうなった）、 CAND_HISTORY では学習しているものの OCHAIRE が未学習の場合に 学習結果が全く反映されなかったり、 します。 また、 同読みの変換を行った場合には必ず同じ字に変換される代わりに、 同読み異字の変換を行おうとした場合に、 前後の文節によって候補が異なる事を特定できる場合でも、 同じ字に変換されてしまいます。

この為、 例えば「です」とか「ます」とか「する」とか「この」とか「また」とか、 個人的によく使う単語は反映されませんし、 一度でも「はままつ」を「浜|待つ」と変換して OCHAIRE学習すると、 二度と「浜松」が第１候補にはならなくなります。 また、 「かなかんじへんかん」を「かな|漢字|変換」と学習した後に、 「かんじ」を「感じ」と学習すると、 「かなかんじへんかん」が「かな|感じ|変換」と変換されてしまいます。   注意１： ここでの「浜|待つ」と「浜松」の例は、 変換結果が望んだ物では無い事は問題ではなく （たった１文節入力しただけなのに、 計算機が人間が何を変換しようとしているかを想像するなんて、 できるわけが無いのですから）、 望んでいない変換から望んでいる変換に 学習しなおす事ができない点が問題です。   注意２： patch3 摘要前（オリジナルどおりの Anthy）ならば、 「はままつ」を「浜松」と変換確定した時点で 「は|ままつ」 「はま|まつ」 「は|ま|まつ」 「はまま|つ」 「は|まま|つ」 「はま|ま|つ」 「は|ま|ま|つ」 の（たぶん）全パターンの学習データを削除するので 「浜松」が第１候補になりますが、 代償？として「浜|待つ」の学習データが完全に消滅します ｛つまるところ、 patch3を摘要しない場合（オリジナルどおりの Anthy の場合）、 普段とちょっとでも文節の切り位置を違えて変換確定すると、 学習データが次々と削除され、 学習が蓄積されにくくなります（経験則）｝。

本パッチは、上記の点の改善を図った物です。 但し、理論的裏付けをしないままに直感と思い付きでやった為、 何が起こるかは判りません。

…… patch13 って……まだ続いたの？……。


patch13 の解説：

オリジナルの Anthy は 文節区切りにビタビアルゴリズム（隠れマルコフモデルの派生らしい）を 使用しています。
このビタビアルゴリズムは、 理論上はトップクラスの変換正答率を誇るものの、 その高確率を出す条件として、 大量の高品質なコーパス（あるいは単語なり文節なりの頻度情報）が 必須となっています。
ざっと調べた感じだと、 どうも新聞数年〜十年分くらいの均質で大量のコーパスが必要だそうです。

Tue,23 Dec,2008 追記：
必要なコーパスの分量の確認をしました。
新聞１ページが 10文字 40行 10段 で 見出しや図や写真や広告などを除外した有意な文章の率が 65％と仮定して、 １ページで 2600文字、１日分で 50000文字、と想定すると。 実装した理論や手法により数倍の開きは有るかもしれませんが。
新聞１週間程度（10^5文字）では既存の伝統的手法よりも悪く、 １ヶ月〜数ヶ月ぶん程度（10^6文字）で条件付きで既存の手法と五分五分、 １年ぶん程度（10^7文字）で条件付きで既存の手法よりも良くなり、 10年ぶん程度（10^8文字）用いれば条件付きで既存の手法よりだいぶ良くなる。
条件付きと言うのは、 使用したコーパスに含まれていない分野の内容の文を変換したり、 使用したコーパスと違う文体で変換した場合、 確実に既存の伝統的手法よりも悪くなる。 らしいです。
また、
「新聞数ヶ月分程度のコーパスを用いるだけで既存の手法よりずっと良くなる」
と主張する論文もありますが、それらの場合、
「変換する内容は、使用したコーパスと全く同じ分野で、文体も全く同じ」
と言う条件が付いていますので、 例えば 新聞の社説担当者が社説を書く為だけに使う場合は重宝するかも知れませんが、 色々な分野の様々な文体で利用される事を前提として考えた場合……。

現実問題として、 Anthy あるいは Anthy に限らず「フリーな」かな漢字変換全般に於いて、 その様な大量の高品質なコーパスを利用する事は困難です （既存のコーパスを利用する場合は購入代金や利用料が払えない、 コーパスを新規作成する場合は 作成や頻度情報の品質向上を行う人員を確保できないもしくは品質が足りない、 など）。

ついでに、オリジナルの Anthy だと、 システム辞書の頻度情報や、蓄積した個人用の学習結果やらは、 ビタビアルゴリズムの確率計算には使用しておらず無駄になっていますし、 システム埋め込みのコーパスだけでは 利用者個人に合わせたチューニングができません。

そういった事などを受けて、 敢えて理論的な優秀さを捨て、 過去の、理論的には優秀では無いけれども そこそこ無難だった（と思う）アルゴリズムに戻すと どうなるかを試してみたのが、 patch13 の 前方ｎ文節最長一致モード です。

有り体に言うと。 モダン手法である隠れマルコフモデルが良いと主張するグループと、 古典手法である前方ｎ文節最長一致が良いと主張するグループと、 両方あるけれども。
検証せずに心証や宣伝や扇動を鵜呑みにするなんて、 なにが漢だ／女がすたる ／エンジニアの矜持は何処にやった／ハッカーじゃねぇ／ワナビーでも （何でもいいので好きなの選んで下さい）、 と言うだけの話です。
変換結果を良くする事を目的として アルゴリズムを変更したわけではありません。

取り敢えず、 前方ｎ文節最長一致（ｎは任意、デフォルトでは３）を実装してみました。
本アルゴリズムのおおよそのイメージとしては、 学習能力を強化した、 VJE / 2005年頃までの ATOK / Canna？ / Wnn？、 ぐらいになると思われます。

設計および実装上は、 前方２文節最長一致だろうが 前方４文節最長一致だろうが 前方８文節最長一致だろうが、 どうとでも選べる様にしてありますが、 面倒なので前方３文節最長一致のみしか動作確認していません。 ${HOME}/.anthy/conf に環境設定ファイルを書けば変更できます。

ついでに。 同環境設定ファイル ${HOME}/.anthy/conf にて、 文節構造のスコアリングを調整できます。
ここの値を変更する事で、 必殺パラメータを編み出す事が出来るかもしれません。

１点だけ、本来の 前方ｎ文節最長一致とは実装を変えてあります。
文節数と全体長は一致するが 個別の文節の長さが違う物が何パターンか有る場合、 本来の 前方ｎ文節最長一致では先頭文節が短い物を選択します（らしい）。
本 patch13 の実装では、 学習結果から得た文節を最優先とし、 学習結果から得た文節が無い場合は、 前述（patch12 パターン１１）の 総合スコア（自立語のスコア × 文節構造のスコア） の加重平均（先頭文節は高加重、後方文節は低加重）が高い物を選択します （加重平均を使うのは、その方がプログラムの実装が楽だから）。
該当する学習結果が無く、スコアも同じ場合は、 本来のアルゴリズム通り先頭文節が短い物を選択します。 変更の根拠はありません、単なる思い付きです。 なお、前方ｎ文節最長一致で複数の候補ができた時に コーパスを使った解決を行わないのは、 現状の Anthy のコーパス情報は 個人の文体とは必ずしも一致しない問題があるのと、 コーパス情報を検索する方法が判らない為です （文節区切りではコーパスを使用しませんが、 変換候補の並び替えでコーパスを使用しているか否かは不明です。 ソースコード読んで探すの面倒）。 patch13ptn17 より、 前方ｎ文節最長一致で複数の候補ができた時に、 文節のコーパスを用いた解決を実装しました （コーパス情報から利用頻度が高い単語を優先する）。 また、変換候補の並び替えの際には、 原作版通りコーパスを用いています。

疑問点：
付属語の遷移のスコアリングに於いて、 オリジナルおよび現状では weak 指定を含むか否かの２通りしか無いが、 システム辞書の頻度値の様な、多段階の指定ができた方が良いのだろうか。
それを始めると、 遷移グラフのメンテナンスをする方の負担が、 ただでさえ大変なのに、さらに爆発する問題が有るので、 積極的に乗り気にはなれないが。
付属語１つ毎に１％低下ルールを試した感じでは、 案外悪くない印象（あくまで印象なので、確証や物証は無い） ではあったものの。

↑ anthy のレポジトリを見たら疑問は解決。
anthy-7??? までの Anthy では、 「:」が１回につき 1/2、「.」が１回につき 1/8、遷移確率を下げ、 複数回あるとそれだけ大きく下げていたが、 anthy-8?00 でコーパスを導入した際に、付属語グラフの仕様を変えて、 遷移確率はコーパスだけを使って算出し、 「.」と「:」は種別も回数も関係無く文節構造のスコアを 1/10 に下げるだけ、 に変更したらしい。

対比：
オリジナルの Anthy（ビタビアルゴリズム）だと、 例えて言うならば「後方∞文節 平均スコア最高」（……そのまんまかも） あるいは「後方∞文節最長一致」 の様な挙動をしている様に感じる事がある。
日本語を左から右に書く感覚で見ていると、 何故そんな変換になったのか判らない誤変換がちょくちょくあるが、 右から左に見ながら計算機の処理を頭の中でシミュレートしてみると、 案外納得がいく誤変換だったりする事がある。
前方３文節最長一致だと文字通り左から右に処理していくので、 日本語を左から右に書く感覚で見ると、 文節区切るの早過ぎ、とか、遅過ぎ、とか、 感覚的にわかりやすい （計算機の処理を頭の中でシミュレートした場合の話）。
ただ、かな漢字変換をする時に、 どんな変換がされるかなど一々考えないで変換する普通の人には、 どちらにせよ関係無い話。

結論：
プログラムの設定値や depgraph やシステム辞書の頻度情報などの、 手作業でのパラメータ調整で変換結果を最高にしようなんて無理、無謀。
オリジナルの Anthy にて、
「手作業で設定するヒューリスティックのパラメータ調整」
と言う方向性を捨てて、
「コーパスからパラメータを自動生成する」
と言う方向性を選んだのは、 至極真っ当。
ただ、不適切だったのは、 公募したコーパスが十分な品質と量になる事を前提とした点と、 個人の文体に合わせた調整機構（学習機能）が無いと言う運用上の点。

↑ コーパスの公募に関する点は、 初期の頃に vagus氏が危惧していた通り （http://vagus.seesaa.net/article/62333234.html） になってしまった様ですが （注：その当時の事は知らないので、 当時の開発関係者のブログや記事を読みかえした結果で書いています）。

Sun,21 Dec,2008 追記：
中古で出回っている辺りの Celeron 500MHz〜1.5GHz クラスや、 ネットブック Atom 1.0〜1.6GHz クラスや、 サブノート Core系 1.0〜1.6GHz クラスを前提にした場合。 新聞数年〜十年分くらいのコーパスを、まともに扱えるんですかね？。 コーパスだけで 100MB〜1GB くらいの容量になっちゃいますよ？。
変換精度が十分に高まる程コーパスを持つと負荷が高すぎて非実用的になり、 許容できる負荷程度にコーパスを減らすと変換精度が今の Anthy 程度になる、 かもしれない。
コーパスを使った変換を行う方面の理論では、この問題が解決できていません。 「コーパスからパラメータを自動生成する」と言う技術は、 10年早い技術なのかもしれない。
この手の「理論通り実装するには計算機の性能が足らない」と言う事を、 いわゆる学者と呼ばれる方々に言うと、相当の高確率で、 「ムーアの法則で性能は３年で２倍になるのだから、 数年も経てば問題は解決する」 と、判で押した様な回答だか文句だかが来ますので、 あらかじめ言っておきますと
……ほんと、あきれるくらいみんなそろってこう言いますけれど……、
一般人が１〜３年毎にパソコンを最新ハイエンド型に買い換えるなんて無理。
「計算機の性能に対するムーアの法則」それ自身に関しても、 現実世界では、 最近３〜５年くらい（おおむね2000〜2005年頃以降くらい）の計算機では 単純性能の向上が頭打ちになっています。
広告／広報／宣伝や論評などで 「ムーアの法則はまだ続いている」旨の主張がありますが、 HyperThreading で性能２倍、 デュアルコアならさらに性能２倍で トリプルコアなら性能３倍で クアッドコアなら性能４倍、 加えてマルチプロセサにすれば更に２倍／３倍／４倍でドン、 と言う計算をして、 「３年で２倍」を達成している裏事情が、勘定に入っていません （それらの主張は、経営的／政治的／経済的な理由により、 故意に裏事情を無視している）。

備考：
本パッチの前方ｎ文節最長一致の実装は、 信じられないほど豪快な手抜き実装をしている為、 本来の前方ｎ文節最長一致とは次元が違うほど、処理が遅いです。 たぶん１〜３桁くらい遅い。 さすがに自分でも頭に来るほど遅かったので、 patch13B にて再実装しました。

注意：
オリジナルの Anthy が駄目とか悪いとかとは言っていません。 現実の運用に必ずしもそぐわない点がある、とは言っていますが。
注意の注意：
現実の運用にそぐわない点が多いとかそぐわない点だらけとは言っていません。
注意の注意の注意：
そぐわない点が有るのが良いとか悪いとかとは言っていません。 そんなのは単なる設計思想の違いです。
注意の注意の注意の注意：
その様な点／違いが存在している、とだけ言っています。
注意の注意の注意の注意の注意：
きりないな。


……、……、……。

しかし、原作のソースコードが、 よくこれだけの大量のパッチ当てに耐えたな。


patch13B の解説：

patch13 の前方ｎ文節最長一致の実装は、 信じられないほど豪快な手抜き実装をしている為、 本来の前方ｎ文節最長一致とは次元が違うほど、処理が遅かった （後述のSun,15 Feb,2009：の項目を参照）。 たぶん本来の速度より１〜３桁くらい遅い筈。

ちょっと長めの文章を入力すると、 すぐに処理が遅くなるのに業を煮やして、 本 patch13B では、 前方ｎ文節最長一致だけ最初から作り直してみた。

結果、patch13 よりも 1.3倍〜１桁くらい、速くなった （後述のSun,08 Mar,2009：の項目を参照。 使用した計算機は、日によって？測定結果が数割ずれる為、 ビタビの変換速度は変わっていないと言う前提で、 速くなった割合を算出した）。 前方４文節最長一致に設定してもビタビより２〜４割速い。 前方５文節最長一致に設定してもビタビより１〜３割速い。 それでも予想より数倍〜１桁遅かった。 読みが同長かつ同読みな異字で、 データを縮退させていない物は、 案外少ないのかもしれない。 あと、再帰処理をそのまま再帰呼び出しで実装したのが遅いのだろうか？。   メモリ消費量も patch13 の前方ｎ文節最長一致より５割〜２桁減った、 前方３文節最長一致ならばビタビと同程度、 でも４とか５文節だとビタビより２倍〜１桁多い。

Anthy のデータ処理の構造はビタビに合わせて作られており、 データ構造を前方ｎ文節最長一致に変換する処理が入る為、 前方ｎ文節最長一致 専用の変換エンジンよりは、 どうしても遅いです。   前方ｎ文節最長一致 専用の変換エンジンの場合、 文章の前方から順に文節区切り処理を行うのと同時に、 処理している部分に該当する内容のみ、 システム辞書や学習データを検索するらしい。   Anthy の場合、 一旦、文章全体から、全ての組み合わせの内容に対して、 システム辞書や学習データを検索してデータを構築してから、 文節区切り処理や変換候補生成を行っている。


iconv対応版の解説：

文字コードのマッピングは、 原作の Anthy や iconv対応前の版では eucJP-MS ですが、 iconv対応版では EUC-JP(JIS X 0208/0212) に変更になります。
eucJP-MS に戻したい場合、 環境設定にて ANTHY_ENCODING_EUCJP_AS_EUCJPMS を指定して下さい。   なお、 各自の環境に於ける iconv が eucJP-MS 非対応の場合、戻せません （例えば、OpenBSD の ports版 libiconv は非対応）。 「libiconv パッチ集（msyk氏）」 にある eucJP-MS 対応版を使用して下さい。 あるいは CP51932 にしたい場合は、 ANTHY_ENCODING_USERDEFINE 指定をした上で 「ANTHY_ENCODING_USERDEFINE_NAME CP51932」指定して下さい。 この場合も、各自の環境に於ける iconv が CP51932 対応である必要があります。   はたまた JIS X 0201 純正？変換にして YEN SIGN を U+00A5 にしたい方は、 eucJP0201？ 対応の iconv（例えば HP-UX版）を使用し、 ANTHY_ENCODING_USERDEFINE 指定をした上で 「ANTHY_ENCODING_USERDEFINE_NAME eucJP0201」指定して下さい。

iconv対応前の場合、 波ダッシュを入力したつもりなのに実際にはチルダが入力されてしまう、 双柱を入力した（略）平行記号が（略）、 マイナス記号（略）横棒（略）、 エムダッシュ（略）水平線（略）、 と言う事があります。   これはマッピングが eucJP-MS になっているせいです。
また、 システム辞書や個人用単語辞書をテキストエディタで編集したり、 EUC-JP なロケールと UTF-8 なロケールを混在して かな漢字変換を行ったりすると、 一部の記号が文字化けする事があります。   これは OSやアプリケーション等が、 EUC-JP のロケールに対して JIS X 0208/0212 EUC-JP である事を前提に処理しているのに対して、 Anthy が eucJP-MS で応答しており、 同じ EUC-JP でも系列が食い違っている為です。
EUC-JP のマッピングを EUC-JP(JIS X 0208/0212) に変更する事により、 これらの問題を解消しています。

オリジナルの Anthy もしくは iconv対応前の版から、 iconv対応後の版に移行する場合、 個人用の単語辞書、個人用の学習データ、 インストール後のシステムの辞書、 全てに於いて、一部の文字の文字コードが変更になります。
全てのデータの文字コードを適切に変換するか、 iconv対応版をインストールする前に 個人用の単語辞書／個人用の学習データ／システムの辞書 全てを削除するか、 して下さい。
文字コードの変換方法は個別の環境によって異なる為、 一般的な変換方法をここで述べる事はできません。   ロケールとか 使っているフロントエンドソフトとか 辞書／学習の形式などによって、 どの変換を行うべきなのか／行わないべきなのかが異なるので、 iconv, nkf, qkc などでサクっと変換、と言う訳にはいきません。
問題になる文字は、

です。 これらの文字を含んでいない場合、変換の必要は有りません。

EUC-JP のマッピングを変更した事の副作用として、 ロケールを UTF-8 にして、 ＭＳゴシック／ＭＳ明朝／みかちゃんフォント などの、 CP51932用フォントあるいは eucJP-MS用フォントを使用した場合、 一部の記号が文字化けします。 これは、 フォントのマッピングが違う、 もしくは Unicode の例示字体が間違っていた件を引きずっている為です。 メイリオフォント等の Unicode ver.3.1以降（ver.4.0以降？）対応／JIS X 0213対応の フォントに更新すれば、治ります、たぶん。

EUC-JP のマッピングが EUC-JP(JIS X 0208/0212) になった事に伴い、 EUC-JP にて JIS X 0212 補助漢字が使える様になります。 一般的な EUC-JP 対応の OS/X/アプリケーションなどでは、 環境設定等を変更する事無く使える筈です。   scim-anthy はソースを改造しないと駄目です （原作版 Anthy に忠実に合わせて？、EUC-JP-MS になっている為）。

EUC-JP にて JIS X 0213 第３・４水準漢字を使う事もできますが、 OS や X や ToolKit やアプリケーションなどが非対応である場合が多い為、 推奨できません。   手元で確認した範囲では、 GTK は JIS X 0213 EUC-JP 第３・４水準漢字に非対応でした。   また、 2007年よりも前の Solaris、 古めの GNU/Linux、 HP-UX や AIX などでは、 標準添付の iconv が JIS X 0213 EUC-JP 第３・４水準漢字に非対応の為、 JIS X 0213 EUC-JP 第３・４水準漢字 対応の GNU libiconv 等を追加でインストールする必要があります。
EUC-JP にて第３・４水準漢字を使いたければ、 ANTHY_ENCODING_EUCJP0213 指定を行なって下さい。   各フロントエンドソフトに於いても変更が必要です。 uim-xim では anthy.scm の変更が必須です、 これ anthy.scm.0213(64KiB) を、 anthy.scm にリネームして適切な所に入れて下さい。 uim の GTK_IM_MODULE や QT_IM_MODULE では、 UTF-8 決め打ちなので、何もする事は有りません（何も出来ません）。 標準の scim では EUC-JP-MS を決め打ちしている為、 EUC-JISX0213 に非対応で、たぶんソース改造が必須です。 iiimf,im,ibus は未確認。

学習データを EUC-JP で保存している場合、 ANTHY_ENCODING_EUCJP_AS_* にて、 JIS X 0208/0212, JIS X 0213, eucJP-MS の どの系列を使用するか選択できます。   但し、システム辞書と同じ系列にする必要があります。
なお、iconv が対応していない系列は使用できません。

iconv対応に伴い、 システム辞書の元データの文字コードの選択幅が広がりました。 set_input_encoding の後に iconv のエンコーディング名を書けば、 そのエンコーディングであると見なして読み込みます。   もっとも、対応している辞書の元データがありませんが。   EUC-KR とか EUC-CN とか EUC-TW とかの元データを 読み込んで辞書を作るとか言う無茶も出来ます。 よみがなをどうするのだと言う問題がありますが。   この機能を使用する場合、 iconvの流派やバージョンによって エンコーディング名が異なる場合が有る事に注意されたし。 mkworddic/mkdic.c の set_input_encoding() に書いてある エンコーディング名の省略名を使えば、 エンコーディング名の違いを可能な限りで吸収します。
なお、 システム辞書の文字コードは UTF-8 と EUC-JP系しか選択できません。 Anthy のシステム辞書の文字コードのフラグが、 UTF-8 と EUC-JP の２択しか無いので。   EUC-JP系の場合、 ANTHY_ENCODING_EUCJP_AS_* にて、 JIS X 0208/0212, JIS X 0213, eucJP-MS の どの系列を使用するか選択できます。

iconv対応に伴い、 かな漢字変換フロントエンドとの 入出力文字コードの選択幅が広がりました。 ANTHY_ENCODING_* を参照。   もっとも、対応しているソフトウェアがありませんが。


用例辞書改造版の解説：

原作版 Anthy にあった用例辞書 udict の機能が、 有効に機能していなかったり誤適用したりしているので、 原作版 udict の機能を丸ごと破棄して、 同様の機能を実装し直してみるテスト。

原作版 Anthy の用例辞書の仕様の解析。

新仕様：


蛇足：

「学習の為に、入力した内容が丸々残るのは嫌」と言う場合、 FILE2_LIMIT を小さくすれば、 学習結果を「入力内容そのまま」から「文節単位の細切れ」に 分解するのが早くなります。 でも、細切れでも解析できますけれどね。 そういう事への本質的な回答は、 「暗号化ファイルシステム使えば？」 だとは思いますが、それは Anthy のやるべき仕事ではない。

＃ でもやっぱり、 FEP は MS-DOS用 WX2 が、 速度、軽さ、変換内容、バランス良く優秀だったと思う今日この頃……、 バグで時々フリーズしたけれどね。 次いで 松茸 かな。 VJE は操作や変換の癖が私には合わなかった。 ATOK は操作や変換の癖が私には合わなかった上に、 推論変換？予測変換？だか何だかと言った高機能化路線に行った挙句に 巨大化して重く遅くなったので嫌い。

原作版 Anthy の文節区切りアルゴリズムは 概して「ビタビアルゴリズム」と呼ばれているが、 本来？の名前は「MBR(Memory Based Reasoning)」らしい。
＃ MBR が文節区切りの確率情報群を生成する一連のアルゴリズムの名前。
＃ ビタビは文節区切りの確率情報群から最適解を探索するアルゴリズムの名前。

原作版 Anthy の統計的手法のアルゴリズムは、 過去に２回変更していて、今の中の人は３人目らしい。
HMM → MEMM → MBR。


継続使用の試験結果：

Sun,02 Sep,2007：

学習のリミットを大きくして、学習情報の収集開始。

（日付不明）：

４ヶ月くらい学習させると、 学習辞書が 1MB くらい、 初動の変換所要時間が CoreDuo 1GHz（注：定格は1.6GHzだが発熱が酷いのでクロックを下げた） だと 1秒〜 2秒くらいで Athlon64 2GHz だと一瞬。 学習量の当初予想量とのずれが大きくなって来たので、 学習の上限量を調整。

Tue,25 Mar,2008：

半年くらい学習させると、 学習辞書が 2MB くらい、 初動の変換所要時間が CoreDuo 1GHz相当だと 2秒〜 4秒くらいで Athlon64 2GHz だと 0.5〜2秒くらい。

Anthy 累計学習量の変化(18KiB) グラフの左端が開始時、右端が約半年経過後、です。 横軸の数値は当方での管理番号で、日数ではありません。

Sun,20 Jul,2008：

10ヶ月経過。 変換結果がまた馬鹿になったと思ったら、 OCHAIRE 学習量が修正後の予想量をまた越えて消去されていた。 学習の上限量を再調整。 SUFFIX_HISTORY/CAND_HISTORY は当初予想量の 1/3 へ減量、 INDEPPAIR は当初予想量の 1/6 へ減量、 OCHAIRE は２度目の倍増、 PREDICTION は当初予想量の 1/2 へ減量、 UNKNOWN_WORD, EXPANDPAIR は当初予想のまま続行。

……、初動の変換が滅茶苦茶重い……。 CoreSolo 1.4GHz相当（注：コアを１つ止めてクロックをちょっと上げた） だと 2秒〜 5秒くらいで Athlon64 2GHz だと 1〜3秒くらい待たされる。 変換初動でいきなり待たされるので、 感覚的にはこの２〜３倍くらいの時間、待たされている気分になる。 ……。 メモリ上に展開されたキャッシュにヒットすれば速いのだが、 キャッシュに当たるのか、外れて読み込むのか不確かなので （一応、起動後初めて変換した時と、学習データを手作業で編集した場合のみ、 読み込みを行なって、それ以外はキャッシュにヒットする筈なのだが）、 結構フラストレーションが溜まる。

CAND_HISTORY は、 「直近８件」ではなく、 「スコアリング付き上位８件」にした方が良い様な気がする。 文節変換は句読点や記号で強制的に切り、 OCHAIRE への記録は 句読点や記号を入れない方が良いと思う。 通常の日本語の文章は、 句読点で区切れ、 文中に記号を含む場合は記号の部分で一単語になっている、 と思うし。 最近のネットやらケータイやらの特殊な文体だとアレだけれども。

個人学習データの OCHAIRE が無圧縮で 4MB ４万件とかある状態だと、 システム埋め込みのコーパス 800KB １万件は、 個人の入力傾向と必ずしも一致していないであろうから、 むしろ邪魔になるのではないかと思った。 今度、コーパスを消したシステム辞書を作って試してみよう。 ……。 もしかして、大量の学習をさせた結果、変換結果が良くなったのって、 大量の OCHAIRE が支えていたりする？。 コーパス５万件目標、とか言う話もあったし。

Sun,17 Aug,2008：

システム埋め込みのコーパスを削除したシステム辞書に交換してから、 約１ヶ月。 変換状況に全く変化無し。 つまりは、大量の個人学習データがあれば、 システム埋め込みのコーパスは全く不要だと言う事か。

個人学習データから、 句読点と括弧と記号と数値を含む項目と、平仮名と片仮名だけからなる項目を、 全て削除してみた。 個人学習データのサイズが 2/3 くらいに縮まった。 変換結果は若干悪くなったが、 それよりもむしろ、 高々この程度の悪化で初動の変換所要時間が 2/3 に縮まった事の方が、 凄い嬉しい。

と言う事で、 前回追記時の 「システムのコーパスは不要」、 「句読点と記号は学習に不要」、の、 裏付けが取れた。

OCHAIRE 学習が、全くサチらない。サチる気配すら無い。 もしかして完全に同一の文章を入力しない限り、 ずっと増えつづけるの？。

変換結果と学習データのサイズと初動変換の遅延からすると、 学習保持量は、2/3 に縮めた後の現時点ぐらいが妥協点だと思われる。 保持量の上限をつけておかないと、 OCHAIRE なんぞは永遠に増えつづけそうな勢いだし。 あとは、学習の保持量を越えた分をどう消すかだが。 素の Anthy の様に、 バッファから超過分を適当 （ここでの「適当に」には、「適切に」の意味合いは含まれない） に消す、だと、 経験則から、消した直後の変換結果が凄く悪くなる。 代替案としては、 最後に利用したタイムスタンプ情報と、 利用した回数の頻度情報を持たせて、 それでスコアリングして点数の高い方を保持、 と言う辺りかなぁ。 スコアリング方法としては、 ［｛（現時刻）−（最後に利用した時刻）｝÷（頻度）］ が小さいほど高得点、辺りが手っ取り早いか？。 どうせ、 このスコアリングのチューニングを行うよりも、 学習量を増やした方が、 変換結果が格段に良くなるのだし。

Fri,05 Sep,2008：

学習させ始めてから１年経過。

Anthy 累計学習量の変化(21KiB) グラフの左端が開始時、右端が約１年経過後、です。 横軸の数値は当方での管理番号で、日数ではありません。 半年経過頃に UNKNOWN_WORD が大きく減っているのは、 手作業で誤学習を削除したから。 １年経過するちょっと前に OCHAIRE, CAND_HISTORY, PREDICTION が大きく減っているのは、 前述の学習結果の整理（手作業）をしたから。 １年経過するちょっと前に last-record1 が大きく減った直後に大きく増えているのは、 スコアリング用データを追加したため。

Mon,13 Oct,2008：

GTK_IM_MODULE=uim だと約5MBの学習データ読み込みに 約 7秒(Core 1.5GHz) や約 3秒(Athlon64 2.2GHz) かかるが、 GTK_IM_MODULE=xim だと 約 3秒(Core 1.5GHz) や約 1.5秒(Athlon64 2.2GHz) だった。 理由は不明。 コンパイル時に -pthreadオプションの有無で比べてみたが、 影響無し。

あと、 GTK_IM_MODULE=uim よりも GTK_IM_MODULE=xim の方が、 消費メモリが仮想サイズで 44MiB 実メモリで 37MiB 少ない。 GTK_IM_MODULE 駄目伝説は未だ健在か。

Athlon64 2.2GHz にて、 patch4の９月版だと GTK_IM_MODULE=uim で約 4秒、xim で約 2秒。 patch5の最新版だと GTK_IM_MODULE=uim で約 3秒、xim で約 1.5秒。 一応、速くなったらしい。 ただ、このくらいだと実感では変わっていない。

MALLOC_OPTIONS をどちらに設定しても、実感の速度は変わらない気がする。 ……。 

% time env MALLOC_OPTIONS=avzj ./test/bin/anthy-agent.static --do-nothing
% time env MALLOC_OPTIONS=avzJ ./test/bin/anthy-agent.static --do-nothing
% time env MALLOC_OPTIONS=avjZ ./test/bin/anthy-agent.static --do-nothing
で比較した所、jz だと１割速くなった。

↑ 学習データのファイルを、eucJP の場合と UTF-8 の場合で、 読み込み速度を比べてみたが、変わらなかった。

Wed,22 Oct,2008：

ビルドして動作確認したら、候補のスコアリングの計算を間違えていた場合の例。


Tue,09 Dec,2008：

学習の活用状況を調べてみた結果。

注意：
2008/08/22以前は、使用回数の記録が無く、最低１回使用した事しか判らないので除外した。
１回しか使用しなかった項目は前述以降の３ヶ月間だけの記録であり、
２回以上使用した項目はそれ以前を含む15ヶ月間の記録である。
その為、統計的な分析はできない事に注意。
また、途中で学習アルゴリズムを何度も変更し、また学習データの選別削除も行っている。
その点でも、統計的な分析はできない事に注意。
あくまで、方向性を読み取る事しかできない（真面目に考えると、それも危ういかも）。
EXPANDPAIR は、その学習アルゴリズム上、使用回数は出鱈目になるので、データ分析をしなかった。
INDEPPAIR は、その学習アルゴリズム上、減る事がある。また、使用回数の記録もあまり正確ではない。

2008/08/29-2008/11/17
		増加件数	2回以上使用した件数	1回	2回	3回	4回	5回	6回	7回	8回	9回	10〜19回	20〜29回	それ以上
OCHAIRE２文節	5998		976	16%		5022	681	175	49	32	10	7	6	5	8		2		1
OCHAIRE３文節	3068		135	 4%		2933	109	 13	 7	 3	 0	0	0	1	1		1		無し
OCHAIRE４文節	1417		 26	 2%		1391	 25	  1	これ以上の回数、使用された項目は無し

OCHAIRE学習の４文節は、費用対効果で見ると、削除対象と見なして良さそう。


2008/08/29〜2008/12/09
セクション		増加件数	２回以上使用した件数	1回	2	3	4	5	6	7	8	9	10〜19	20〜29	30〜	40〜	50〜∞
CAND_HISTORY		  9233		 4962	54%		4271	2292	917	493	301	185	142	91	80	291	87	32	14	37
INDEPPAIR                  474		  177	37%
OCHAIRE                  13159		 1632	12%		11527	1132	279	84	55	24	14	11	5	19	6	2	0	1
    うち OCHAIRE ２文節	  8515		 1385	16%		7130	942	246	73	49	24	12	11	4	17	4	2	0	1
    うち OCHAIRE ３文節	  4644		  247	 5%		4397	190	33	11	6	0	2	0	1	2	2	0	0	0
SUFFIX_HISTORY              66		   51	77%
UNKNOWN_WORD               163		   93	57%
総数			 23567		 7077	30%	総量約1.4MiB

OCHAIRE以外の学習は、案外役に立っているらしい。
OCHAIRE学習は、思った程役には立っていないらしい。
OCHAIRE３文節は諦めて、OCHAIRE２文節の有効活用を考えた方が良いのかも知れない。
＃ ３文節の場合、中間文節は、両端の区切りが確定した文節として、決定しやすい（誤変換しにくい）。
＃ ２文節の場合、中間の区切りは確定できるが、文節の両端の区切りの確定は行いにくい（誤変換しやすくなる）。
＃ 現状の Anthy の実装は、「両端の区切りが確定した文節の列挙」と言う形態になっているので、OCHAIRE２文節は扱いにくいのよ。

ここには掲載していない分析結果によると、 OCHAIRE学習に関して、 直近に学習した 3000〜3200件は２回以上使用される率が高く、 直近に学習した 3200件より古い学習データになると ２回以上使用される率が下がった。 ちょうど、3000〜3200件の点で折れるグラフになった。
但し、丁度その頃に、学習アルゴリズムの変更、 もしくは学習データの手動選別を行ったのかも知れない可能性が大いにある。 あるいは丁度その頃に、書く文章の種類が大きく変わったとか。
……3000〜3200件と言うと……、2008年10月中旬。 丁度 patch7/patch8 の初版が完成した頃……、 でもOCHAIREアルゴリズムは変更していない。 ……ああ、丁度その頃に、書く文章の種類が、 仕様書の類から連絡／手配の類に変わったわ……、駄目じゃん。

Sun,01 Feb,2009：

Anthy 累計学習量の変化(16KiB) グラフの左端が開始時、右端が約１年半経過後、です。 横軸の数値は当方での管理番号で、日数ではありません。   時々学習量が大きく減っているのは、 手作業で誤学習の削除と学習内容の整理をしたから。   INDEPPAIR と PREDICTION が途中で消えているのは、 他の項目に変更したり、他の項目と統合したりした為。   ２回、last-record1 が大きく増えているのは、 スコアリング用データを追加したため。

UNKNOWN_WORD と SUFFIX_HISTORY は、ついにほぼ飽和したっぽい。 PREFIX_HISTORY は、そもそも無いらしい。

CAND_HISTORY は微増（と言っても桁が大きいが）が続き、 OCHAIRE は飽和する気配全く無し。

INDEP_HISTORY と DEP_HISTORY と OCHAIRE.withDEP と OCHAIRE.withoutDEP は、 最近追加した学習項目の為、動向はまだ不明。

この記録を採った後に、 付属語無しOCHAIRE にまだ対応していなかった頃に採録した 付属語付きと思われる（語尾が平仮名になっている）OCHAIRE ３文節の 学習データの内、 利用頻度が１回の物（約14,000件、全OCHAIRE の約 28％）を削除、 利用頻度が１回以上の物（約500件、全OCHAIRE の約 1％）を 付属語無しOCHAIREに変換して再登録、 した。 付属語無しと思われる（語尾が漢字）OCHAIRE ３文節 （約3,500件、全OCHAIRE の約 7％）は、そのまま継続。 約32,000件、約64％は、OCHAIRE ２文節だった。

併せて、 先頭文節に自立語が付いていない可能性がある（ひらがなで始まっている） OCHAIRE 約2,300件 を削除。

これで、 6MBくらいまで肥大化していた学習データが、 4MB弱まで減った。


Fri,13 Feb,2009：Sun,15 Feb,2009：

ふとした思い付きで、変換速度のベンチマークを採ってみた。

	使用するのは anthy-9100h.patch13ptn19.2009212。
	辞書・付属語グラフ・コーパスは 9100h標準品。
	変換処理は anthy-agent --anonymous < data > /dev/null
	変換結果が望んだ物であるか否かの判定はしない。
	学習は、記録・反映ともに全て無効。但し、変換確定結果から記録すべきデータの抽出だけは行っている。
	３回測って全消費時間が中央値だったデータを採用。

                            全          ユーザランド    カーネル内      SHM    data   stack  ページ   コンテキスト
                            消費時間    消費時間        消費時間        使用量 使用量 使用量 割当回数 スイッチ回数
時間単位は秒

変換させる内容は、１文当たり２文節を 500件（単純に、普段の学習データから取り出した物）
Athlon64 2.2GHz (FreeBSD/amd64 6.4-RELEASE-p3 GENERIC) CnQ無効 MALLOC_OPTIONS=AvzJ
無変換(-g3 -O0)：           0.05        0.04            0.00             24kiB 433kiB 146kiB  395      15
ビタビ(-g3 -O0)：           5.14        3.86            0.18             23kiB 818kiB 126kiB 1140     881
２文節最長一致(-g3 -O0)：   3.52        2.86            0.17             23kiB 836kiB 127kiB 1105     660
３文節最長一致(-g3 -O0)：   3.93        3.04            0.17             23kiB 846kiB 125kiB 2548     691
４文節最長一致(-g3 -O0)：   4.02        3.25            0.18             23kiB 872kiB 127kiB 6992     744

変換させる内容は、１文当たり２文節を 500件（単純に、普段の学習データから取り出した物）
Athlon64 2.2GHz (FreeBSD/amd64 6.4-RELEASE-p3 GENERIC) CnQ無効 MALLOC_OPTIONS=AvzJ
無変換(-g0 -O2)：           0.04        0.04            0.00             22kiB 397kiB 153kiB  404      10
ビタビ(-g0 -O2)：           2.25        1.76            0.21             19kiB 760kiB 126kiB 1115     474
２文節最長一致(-g0 -O2)：   1.73        1.42            0.21             20kiB 787kiB 129kiB 1129     418
３文節最長一致(-g0 -O2)：   1.77        1.46            0.29             19kiB 789kiB 126kiB 2759     419
４文節最長一致(-g0 -O2)：   2.09        1.69            0.20             20kiB 828kiB 129kiB 7546     449

変換させる内容は、１文当たり10文節を 100件（同じ内容を100回）
Athlon64 2.2GHz (FreeBSD/amd64 6.4-RELEASE-p3 GENERIC) CnQ無効 MALLOC_OPTIONS=AvzJ
無変換(-g0 -O2)：           0.02        0.02            0.00             30kiB  432kiB 192kiB    387       4
ビタビ(-g0 -O2)：           7.88        4.41            1.44             20kiB 1109kiB 129kiB    706    1243
２文節最長一致(-g0 -O2)：   6.88        3.65            1.54             19kiB 1090kiB 126kiB    706    1190
３文節最長一致(-g0 -O2)：   8.11        4.57            1.61             20kiB 1184kiB 129kiB  40786    1413
４文節最長一致(-g0 -O2)：  36.12       20.82            5.05             20kiB 3671kiB 129kiB 737304    5822

変換させる内容は、１文当たり10文節を 100件（同じ内容を100回）
Athlon64 2.2GHz (FreeBSD/amd64 6.4-RELEASE-p3 GENERIC) CnQ無効 MALLOC_OPTIONS=avjz
無変換(-g0 -O2)：           0.01        0.01            0.00             30kiB  434kiB 192kiB    387       5
ビタビ(-g0 -O2)：           7.88        4.36            1.34             20kiB 1110kiB 129kiB    706    1245
２文節最長一致(-g0 -O2)：   6.72        3.67            1.35             19kiB 1090kiB 126kiB    706    1053
３文節最長一致(-g0 -O2)：   7.64        4.28            1.58             20kiB 1174kiB 128kiB  40786    1339
４文節最長一致(-g0 -O2)：  31.40       17.15            5.11             19kiB 3517kiB 127kiB 737304    4625


変換させる内容は、１文当たり２文節を 500件（単純に、普段の学習データから取り出した物）
Core 1667MHz (FreeBSD/i386 6.4-RELEASE-p3 GENERIC) SpeedStep無効 MALLOC_OPTIONS=AvzJ
無変換(-g0 -O2)：           0.07        0.06            0.00             17kiB  264kiB 142kiB  292      28
ビタビ(-g0 -O2)：           6.62        5.09            1.46             15kiB  796kiB 126kiB 1012    2163
２文節最長一致(-g0 -O2)：   5.34        3.80            1.48             15kiB  821kiB 126kiB  939    1791
３文節最長一致(-g0 -O2)：   6.08        4.40            1.61             15kiB  851kiB 126kiB 1718    2153
４文節最長一致(-g0 -O2)：   6.29        4.47            1.74             15kiB 1167kiB 126kiB 3349    2236

変換させる内容は、１文当たり10文節を 100件（同じ内容を100回）
Core 1667MHz (FreeBSD/i386 6.4-RELEASE-p3 GENERIC) SpeedStep無効 MALLOC_OPTIONS=AvzJ
無変換(-g0 -O2)：           0.05        0.04            0.00             19kiB  221kiB 153kiB    292      14
ビタビ(-g0 -O2)：          17.25       13.65            3.42             15kiB  838kiB 126kiB    579    5560
２文節最長一致(-g0 -O2)：  13.69       10.17            3.33             15kiB  832kiB 126kiB    578    4676
３文節最長一致(-g0 -O2)：  18.18       14.42            3.52             15kiB  919kiB 126kiB  48743    6136
４文節最長一致(-g0 -O2)： 104.28       98.07            4.74             15kiB 6718kiB 126kiB 232977   32470


結果：
短い文ならば、ビタビより前方ｎ文節最長一致の方が、１〜２割、速いらしい。
長い文だと、前方ｎ文節最長一致のｎ値が大きくなるにつれ、どんどん遅くなるらしい。長い文でも前方２文節最長一致ならばビタビより速いらしい。
前方３文節最長一致よりビタビの方が、１割？、メモリ消費量が少ないらしい。
-O2 でも、２文節の変換を１件、3〜5[ms] かかる。10文節だと 150〜200[ms] もかかってしまうらしい。

感想（根拠無しの思い付き）：
短い文の時にビタビが遅いのは、使用していた時の感触通りだった。
前方ｎ文節最長一致の処理時間が文の長さにもろに影響されるのも、使用していた時の感触通りだった。
前方ｎ文節最長一致において、文の長さが長くなればなる程、ここまで遅くなるのは予想外だった。実装で手抜きしすぎたか。気合入れてちゃんと実装すれば、１〜３桁は速くなるとは思うのだけれど。
前方３文節最長一致のメモリ消費量が、明らかにビタビより多いのは予想外。やっぱり実装で手抜きしすぎたか。
全般に、思っていたよりも１桁〜２桁遅いので、計算量としては結構大きいらしい。前方ｎ文節最長一致に関しては、なんというか実装で手抜きしすぎ。


備考：
本パッチの前方ｎ文節最長一致の実装は、
「可能な単語の全組み合わせをｎ段連ねて全探索」
しかも
「文節区切り位置を１段決定する毎に、これまでの探索結果を全部捨てて再度全探索」
とかいう、凄い馬鹿げた実装になっている為、
本来の前方ｎ文節最長一致とは次元が違うほど遅くなっています。たぶん１〜３桁くらい遅い。
＃ 本来の前方ｎ文節最長一致の実装ならば、
＃  読みが同じ長さの文節の探索は１回、
＃  文節区切り位置を１段決定する毎に深さ方向に１段分延長、
＃ で良いが、
＃  本パッチは全探索なので同読み異字の文節が多ければ多いほど……、
＃  しかも１段毎に全探索なので入力した文章が長ければ長いほど……。

Sun,08 Mar,2009：

patch13B にて、再度ベンチマーク。

	使用するのは anthy-9100h.patch13Bptn20.2009308。
	辞書・付属語グラフ・コーパスは 9100h標準品。
	変換処理は anthy-agent --anonymous < data > /dev/null
	変換結果が望んだ物であるか否かの判定はしない。
	学習は、記録・反映ともに全て無効。但し、変換確定結果から記録すべきデータの抽出だけは行っている。
	３回測って全消費時間が中央値だったデータを採用。

                            全          ユーザランド    カーネル内      SHM    data   stack  ページ   コンテキスト
                            消費時間    消費時間        消費時間        使用量 使用量 使用量 割当回数 スイッチ回数
時間単位は秒

変換させる内容は、１文当たり２文節を 500件（単純に、普段の学習データから取り出した物）
Core 1667MHz (FreeBSD/i386 6.4-RELEASE-p3 GENERIC) SpeedStep無効 MALLOC_OPTIONS=AvzJ
無変換(-g1 -O2)：           0.08        0.07            0.00             16kiB  255kiB 128kiB  278      23
ビタビ(-g1 -O2)：           8.06        6.04            1.94             15kiB  882kiB 126kiB 1038    2303
２文節最長一致(-g1 -O2)：   5.43        3.84            1.53             15kiB  801kiB 126kiB 1016    1879
３文節最長一致(-g1 -O2)：   5.87        4.16            1.64             15kiB  949kiB 126kiB  946    2030
４文節最長一致(-g1 -O2)：   5.97        4.11            1.78             15kiB  829kiB 126kiB 1477    2162

変換させる内容は、１文当たり10文節を 100件（同じ内容を100回）
Core 1667MHz (FreeBSD/i386 6.4-RELEASE-p3 GENERIC) SpeedStep無効 MALLOC_OPTIONS=AvzJ
無変換(-g1 -O2)：           0.04        0.04            0.00             16kiB  244kiB 128kiB  278      14
ビタビ(-g1 -O2)：          20.36       16.23            3.88             15kiB  848kiB 126kiB  595    6721
２文節最長一致(-g1 -O2)：  14.19       10.45            3.59             15kiB  836kiB 126kiB  575    4552
３文節最長一致(-g1 -O2)：  14.32       10.71            3.45             15kiB  859kiB 126kiB  581    4727
４文節最長一致(-g1 -O2)：  14.56       10.83            3.57             15kiB  893kiB 126kiB 1221    4695
５文節最長一致(-g1 -O2)：  15.45       11.69            3.57             15kiB  980kiB 126kiB 6791    5153

Tue,21 Apr,2009：

Anthy 累計学習量の変化(22KiB) グラフの左端が開始時、右端が約１年８ヶ月経過後、です。 横軸の数値は当方での管理番号で、日数ではありません。   管理番号152にて、小計算出期間を変えている。   時々学習量が大きく減っているのは、 手作業で誤学習の削除と学習内容の整理をしたから。   INDEPPAIR と PREDICTION が途中で消えているのは、 他の項目に変更したり、他の項目と統合したりした為。   時々 last-record1 が大きく増えているのは、 スコアリング用データを追加したため。

学習の利用効率と活用率。

注意：
セクション毎に集計期間がバラバラなので、セクション同士の合算は、してはいけません。
2008/08/22以前は使用回数の記録が無く、最低１回使用した事しか記録していない。2008/08/22以降は、２回以上使用した場合に、その旨記録されている。
１回しか使用しなかったデータと、２回以上使用したデータは、集計期間が異なるので、統計的な分析はできない事に注意。
また、途中で学習アルゴリズムを何度も変更し、また学習データの選別削除も行っている。その点でも、統計的な分析はできない事に注意。
あくまで、方向性を読み取る事しかできない（真面目に考えると、それも危ういかも）。


直前に変換した内容を保持しておけば、活用出来るかもしれない学習：
セクション          内容                                                      種類で数えた場合              延べ利用回数で数えた場合      利用回数を
                                                                              学習した  ２回以上使用した    学習した  ２回以上使用した    学習した
                                                                              総数      総数      率        のべ回数  のべ回数  率        期間
DATA_SAMPLING 2I    前の文節の自立語 ＋ この文節の自立語                       2975       372     13％       3630      1027     28％      約２ヶ月半
DATA_SAMPLING 3I    前々文節の自立語 ＋ 前文節の自立語 ＋ この文節の自立語     1833        73      4％       1918       158      8％      約２ヶ月半
DATA_SAMPLING 2D    前の文節の付属語 ＋ この文節の付属語                       1977       494     25％       5648      4165     74％      約２ヶ月半
DATA_SAMPLING 3D    前々文節の付属語 ＋ 前文節の付属語 ＋ この文節の付属語     1566       181     12％       2199       814     37％      約２ヶ月半
DATA_SAMPLING 2ID   前の文節の自立語 ＋ この文節の付属語                       4070       666     16％       5638      2234     40％      約２ヶ月半
OCHAIRE 2.wIwD      前の文節 ＋ この文節                                       4134       547     13％       5340      1753     33％      約３ヶ月
OCHAIRE 2.wIwoD     前の文節 ＋ この文節の自立語                               5338       966     18％       8140      3768     46％      約３ヶ月
OCHAIRE 2.woIwD     前の文節の付属語 ＋ この文節                               2261       272     12％       2817       828     29％      約２ヶ月半
OCHAIRE 2.woIwoD    前の文節の付属語 ＋ この文節の自立語                       2075       472     23％       3350      1747     52％      約２ヶ月半
OCHAIRE 2               OCHAIRE 2.* 系統の総計                                42470      3641      9％      50299     11470     23％      約８ヶ月
OCHAIRE 3.wIwoD     前々文節 ＋ 前の文節 ＋ この文節の自立語                   2714       149      5％       3145       580     18％      約３ヶ月
OCHAIRE 3.woIwoD    前々文節の付属語 ＋ 前の文節 ＋ この文節の自立語           1389        68      5％       1473       152     10％      約２ヶ月半
OCHAIRE 3               OCHAIRE 3.* 系統の総計                                 7762       459      6％       8655      1352     16％      約８ヶ月

変換を行う各文節内で閉じた学習：
CAND_HISTORY        文節丸ごと                                                29042      8168     28％      73207     52333     71％      約８ヶ月
DEP_HISTORY         付属語のみ                                                 1291       504     39％       9443      8656     92％      約２ヶ月半
EXPANDPAIR          文節区切り位置を伸ばした                                    958       277     29％       1704      1023     60％      約８ヶ月
INDEP_HISTORY       自立語のみ                                                 3908      2086     53％      21577     19755     92％      約３ヶ月
PREFIX_HISTORY      接頭辞のみ                                                    5         2     40％         22        19     86％      約１ヶ月半
SUFFIX_HISTORY      接尾辞のみ                                                  176        90     51％       1058       972     92％      約８ヶ月
UNKNOWN_WORD        単語の自動登録（ひらがな語、カタカナ語）                    623        96     15％        904       377     42％      約８ヶ月

「種類で数えた場合」の「２回以上使用した率」は、学習データの利用効率。
「延べ利用回数で数えた場合」の「２回以上使用した率」は、利用者の役に立った割合。


備考：
DATA_SAMPLING セクションは、オプション ENABLE_DATASAMPLING を有効にした時のみ、記録される。

Fri,12 Jun,2009：

学習の利用効率と活用率。

セクション          内容                                                      種類で数えた場合              延べ利用回数で数えた場合      利用回数を
                                                                              学習した  ２回以上使用した    学習した  ２回以上使用した    学習した
                                                                              総数      総数      率        のべ回数  のべ回数  率        期間
DATA_SAMPLING 2I    前の文節の自立語 ＋ この文節の自立語                       5440       833     15％       7127      2520     35％      約４ヶ月
DATA_SAMPLING 3I    前々文節の自立語 ＋ 前文節の自立語 ＋ この文節の自立語     3774       202      5％       4043       471     12％      約４ヶ月
DATA_SAMPLING 2D    前の文節の付属語 ＋ この文節の付属語                       3244       847     26％      10750      8353     78％      約４ヶ月
DATA_SAMPLING 3D    前々文節の付属語 ＋ 前文節の付属語 ＋ この文節の付属語     2953       440     15％       4524      2011     44％      約４ヶ月
DATA_SAMPLING 2ID   前の文節の自立語 ＋ この文節の付属語                       7026      1308     19％      10775      5057     47％      約４ヶ月
OCHAIRE 2.wIwD      前の文節 ＋ この文節                                       7202       954     13％       9338      3090     33％      約４ヶ月半間
OCHAIRE 2.wIwoD     前の文節 ＋ この文節の自立語                               8785      1691     19％      13813      6719     49％      約４ヶ月半間
OCHAIRE 2.woIwD     前の文節の付属語 ＋ この文節                               5126       689     13％       6701      2264     34％      約４ヶ月間
OCHAIRE 2.woIwoD    前の文節の付属語 ＋ この文節の自立語                       4730      1120     24％       8601      4991     58％      約４ヶ月間
OCHAIRE 2           最後に利用したのが 29 Aug,2008 以前                       18786        19      0％      18806        39      0％      不明
OCHAIRE 2           最後に利用したのが 30 Aug,2008 〜 26 Oct,2008              3447       444     13％       4054      1051     26％      約２ヶ月間
OCHAIRE 2           最後に利用したのが 27 Oct,2008 〜 23 Dec,2008              4496       581     13％       5334      1419     27％      約２ヶ月間
OCHAIRE 2           最後に利用したのが 27 Oct,2008 〜 23 Dec,2008              4496       581     13％       5334      1419     27％      約２ヶ月間
OCHAIRE 2           最後に利用したのが 24 Dec,2008 〜 19 Feb,2009              3543       460     13％       4257      1174     28％      約２ヶ月間
OCHAIRE 2           最後に利用したのが 19 Feb,2009 〜 17 Apr,2009              9386      1120     12％      11203      2937     26％      約２ヶ月間
OCHAIRE 2           最後に利用したのが 18 Apr,2009 〜 12 Jun,2009             14266      3098     22％      24672     13504     55％      約２ヶ月間
OCHAIRE 2             最後に利用したのが 19 Feb,2009 〜 14 Mar,2009            3105       318     10％       3608       821     23％      約１ヶ月間
OCHAIRE 2             最後に利用したのが 14 Mar,2009 〜 06 Apr,2009            4043       475     12％       4787      1219     25％      約１ヶ月間
OCHAIRE 2             最後に利用したのが 06 Apr,2009 〜 29 Apr,2009            5566       940     17％       7322      2696     37％      約１ヶ月間
OCHAIRE 2             最後に利用したのが 30 Apr,2009 〜 22 May,2009            6139      1205     20％       9113      4179     46％      約１ヶ月間
OCHAIRE 2             最後に利用したのが 22 May,2009 〜 12 Jun,2009            4799      1280     27％      11045      7526     68％      約１ヶ月間
OCHAIRE 2               OCHAIRE 2.* 系統の総計                                53924      5722     11％      68326     20124     29％      約９ヶ月半
OCHAIRE 3.wIwoD     前々文節 ＋ 前の文節 ＋ この文節の自立語                   4817       278      6％       5445       906     17％      約４ヶ月半
OCHAIRE 3.woIwoD    前々文節の付属語 ＋ 前の文節 ＋ この文節の自立語           2740       181      7％       2997       438     15％      約４ヶ月
OCHAIRE 3               OCHAIRE 3.* 系統の総計                                11196       694      6％      12522      2020     16％      約９ヶ月半

CAND_HISTORY        文節丸ごと                                                31214      9278     30％      85939     64003     74％      約９ヶ月半
DEP_HISTORY         付属語のみ                                                 1830       730     40％      16678     15578     93％      約４ヶ月
EXPANDPAIR          文節区切り位置を伸ばした                                   1087       347     32％       2043      1303     64％      約９ヶ月半
INDEP_HISTORY       自立語のみ                                                 4855      2676     55％      34240     32061     94％      約４ヶ月半
PREFIX_HISTORY      接頭辞のみ                                                    5         3     60％         44        42     95％      約３ヶ月
SUFFIX_HISTORY      接尾辞のみ                                                  185       102     55％       1259      1176     93％      約９ヶ月半
UNKNOWN_WORD        単語の自動登録（ひらがな語、カタカナ語）                    632        96     15％        913       377     41％      約９ヶ月半

延べ利用回数での利用効率から言うと、 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 は欲しいのだが。

Wed,08 Jul,2009, Thu,09 Jul,2009, Wed,09 Sep,2009, Thu,10 Sep,2009：

変換所要時間（変換速度）の比較。


１文の変換内容（10文節）：
「tatoebakonnnakanzinobunsyouga10bunnsetutonarunaiyouwohenkansurutokekkahadounarunodarou.(space)」

変換内容を平仮名表記：
「たとえばこんなかんじのぶんしょうが１０ぶんせつとなるないようをへんかんするとけっかはどうなるのだろう。」

期待する変換結果：
「(3 ((UL RV) "例えば" 0 3) ((UL) "こんな感じの" 0 4) ((UL) "文章が" 0 6) ((UL) "１０文節となる" 0 3) ((UL) "内容を" 0 5) ((UL) "変換すると" 0 5) ((UL) "結果は" 0 7) ((UL) "どうなるのだろう" 0 2) ((UL) "。" 0 3))」

プログラム内で同じ変換を1000回（Canna,FreeWnn,sj3）もしくは 100回（Anthy）行い、 その処理に要する時間を計測し、１回当たりの変換時間を算出した。
変換結果が望んだ通りになっているか否かの判定は行わない。 

約2.6秒		月面との通信での遅延時間（往復）。
約1.3秒		月面との通信での遅延時間（片道）。
930msec		のび太が立った状態から昼寝を開始するのに必要な時間（初期の連載を除く）。
239msec		静止衛星との通信での遅延時間（往復）。
200msec		チーラの一日
139msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。MBRビタビ(-g3 -O0)、PentiumD 3.2GHz OpenBSD44R。
129msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。前方４文節最長一致(-g3 -O0)、PentiumD 3.2GHz OpenBSD44R。
129msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。前方３文節最長一致(-g3 -O0)、PentiumD 3.2GHz OpenBSD44R。
128msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。前方２文節最長一致(-g3 -O0)、PentiumD 3.2GHz OpenBSD44R。
119msec		静止衛星との通信での遅延時間（片道）。
111msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。MBRビタビ(-g3 -O0)、PentiumD 3.2GHz OpenBSD44R。
107msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。MBRビタビ(-g3 -O2)、PentiumD 3.2GHz OpenBSD44R。
102msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。前方４文節最長一致(-g3 -O2)、PentiumD 3.2GHz OpenBSD44R。
101msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。前方３文節最長一致(-g3 -O2)、PentiumD 3.2GHz OpenBSD44R。
101msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。前方２文節最長一致(-g3 -O2)、PentiumD 3.2GHz OpenBSD44R。
96msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。前方４文節最長一致(-g3 -O0)、PentiumD 3.2GHz OpenBSD44R。
93msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。前方３文節最長一致(-g3 -O0)、PentiumD 3.2GHz OpenBSD44R。
93msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。前方２文節最長一致(-g3 -O0)、PentiumD 3.2GHz OpenBSD44R。
83msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。MBRビタビ(-g3 -O2)、PentiumD 3.2GHz OpenBSD44R。
74msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。前方４文節最長一致(-g3 -O2)、PentiumD 3.2GHz OpenBSD44R。
72msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。前方３文節最長一致(-g3 -O2)、PentiumD 3.2GHz OpenBSD44R。
72msec		Anthy拙作パッチ版（追加辞書有効）で、１文の内容を変換するのに要する時間。前方２文節最長一致(-g3 -O2)、PentiumD 3.2GHz OpenBSD44R。
64msec		Anthy-9100h原作版（通常辞書のみ） + alt-depgraph-090525 で、１文の内容を変換するのに要する時間。ビタビ(-g3 -O0)、PentiumD 3.2GHz OpenBSD44R。
64msec		Anthy-9100h原作版（通常辞書のみ）で、１文の内容を変換するのに要する時間。MBRビタビ(-g3 -O0)、PentiumD 3.2GHz OpenBSD44R。
63msec		Anthy-9100h原作版（通常辞書のみ）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。MBRビタビ(-g3 -O0)、PentiumD 3.2GHz OpenBSD44R。
50msec		蒸着。
44msec		Anthy-9100h原作版（通常辞書のみ） + alt-depgraph-090525 で、１文の内容を変換するのに要する時間。MBRビタビ(-g3 -O2)、PentiumD 3.2GHz OpenBSD44R。
43msec		Anthy拙作パッチ版(Sat,08 Oct,2011)（追加辞書有効）で、１文の内容を変換するのに要する時間。MBRビタビ(-g3 -O3)、Phenom 2.0GHz OpenBSD48R/amd64。
43msec		Anthy-9100h原作版（通常辞書のみ）で、１文の内容を変換するのに要する時間。MBRビタビ(-g3 -O2)、PentiumD 3.2GHz OpenBSD44R。
43msec		Anthy-9100h原作版（通常辞書のみ）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。MBRビタビ(-g3 -O2)、PentiumD 3.2GHz OpenBSD44R。
39msec		Anthy拙作パッチ版(Sat,08 Oct,2011)（追加辞書有効）で、１文の内容を変換するのに要する時間。MBRダイクストラ２コアモード(-g3 -O3)、Phenom 2.0GHz OpenBSD48R/amd64。
33msec		フレーム速度1/30での１フレーム。
18msec		Anthy拙作パッチ版(Sat,08 Oct,2011)（追加辞書有効）で、１文の内容を変換するのに要する時間。MBRビタビ(-g3 -O3)、Core i5 2.4GHz FreeBSD90B3/amd64。
17msec		フレーム速度1/60での１フレーム。
17msec		Anthy拙作パッチ版(Sat,08 Oct,2011)（追加辞書有効）で、１文の内容を変換するのに要する時間。MBRダイクストラ２コアモード(-g3 -O3)、Core i5 2.4GHz FreeBSD90B3/amd64。
16.667msec	チーラの一時間
13msec		Anthy拙作パッチ版(Sat,08 Oct,2011)（追加辞書有効）で、１文の内容を変換するのに要する時間。文節数最小(-g3 -O3)、Phenom 2.0GHz OpenBSD48R/amd64。
12msec		Anthy拙作パッチ版(Sat,08 Oct,2011)（追加辞書有効）で、１文の内容を変換するのに要する時間。前方３文節最長一致(-g3 -O3)、Phenom 2.0GHz OpenBSD48R/amd64。
8.69msec	Canna-3.5b2 + alt-cannadicのgcanna（anthyの通常辞書とほぼ同量）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。-g3 -O2、PentiumD 3.2GHz OpenBSD44R。
8.00msec	Anthy拙作パッチ版(Sat,08 Oct,2011)（追加辞書有効）で、１文の内容を変換するのに要する時間。文節数最小(-g3 -O3)、Core i5 2.4GHz FreeBSD90B3/amd64。
7.40msec	Anthy拙作パッチ版(Sat,08 Oct,2011)（追加辞書有効）で、１文の内容を変換するのに要する時間。前方３文節最長一致(-g3 -O3)、Core i5 2.4GHz FreeBSD90B3/amd64。
7.16msec	Canna-3.5b2（Canna標準辞書）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。-g0 -O2、PentiumD 3.2GHz OpenBSD44R。
6.63msec	Canna-3.5b2 + alt-cannadicのgcanna（anthyの通常辞書とほぼ同量）で、１文の内容を変換するのに要する時間。-g3 -O2、PentiumD 3.2GHz OpenBSD44R。
5.47msec	Canna-3.5b2（Canna標準辞書）で、１文の内容を変換するのに要する時間。-g0 -O2、PentiumD 3.2GHz OpenBSD44R。
3.69msec	FreeWnn-1.1.1-a021（FreeWnn標準辞書）で、１文の内容を変換するのに要する時間。-g3 -O0、PentiumD 3.2GHz OpenBSD44R。
3.13msec	FreeWnn-1.1.1-a021（FreeWnn標準辞書）で、１文の内容を変換するのに要する時間。-g3 -O2、PentiumD 3.2GHz OpenBSD44R。
1.389msec	チーラの十分
0.94msec	sj3-2.0.1.23（ネットワークソケット接続モード）（追加辞書でanthyの通常辞書の４割くらいの量）で、１文の内容を変換するのに要する時間。-g0 -O0、PentiumD 3.2GHz OpenBSD44R。
0.88msec	sj3-2.0.1.23（ファイルソケット接続モード）（追加辞書でanthyの通常辞書の４割くらいの量）で、１文の内容を変換するのに要する時間。-g0 -O0、PentiumD 3.2GHz OpenBSD44R。
0.81msec	sj3-2.0.1.23（ネットワークソケット接続モード）（sj3標準辞書）で、１文の内容を変換するのに要する時間。-g0 -O0、PentiumD 3.2GHz OpenBSD44R。
0.74msec	sj3-2.0.1.23（ファイルソケット接続モード）（sj3標準辞書）で、１文の内容を変換するのに要する時間。-g0 -O0、PentiumD 3.2GHz OpenBSD44R。
0.63msec	sj3-2.0.1.23（ネットワークソケット接続モード）（追加辞書でanthyの通常辞書の４割くらいの量）で、１文の内容を変換するのに要する時間。-g0 -O2、PentiumD 3.2GHz OpenBSD44R。
0.57msec	sj3-2.0.1.23（ファイルソケット接続モード）（追加辞書でanthyの通常辞書の４割くらいの量）で、１文の内容を変換するのに要する時間。-g0 -O2、PentiumD 3.2GHz OpenBSD44R。
0.53msec	sj3-2.0.1.23（ネットワークソケット接続モード）（sj3標準辞書）で、１文の内容を変換するのに要する時間。-g0 -O2、PentiumD 3.2GHz OpenBSD44R。
0.52msec	sj3-2.0.1.23（ネットワークソケット接続モード）（追加辞書でanthyの通常辞書の４割くらいの量）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。-g0 -O0、PentiumD 3.2GHz OpenBSD44R。
0.48msec	sj3-2.0.1.23（ファイルソケット接続モード）（sj3標準辞書）で、１文の内容を変換するのに要する時間。-g0 -O2、PentiumD 3.2GHz OpenBSD44R。
0.46msec	sj3-2.0.1.23（ファイルソケット接続モード）（追加辞書でanthyの通常辞書の４割くらいの量）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。-g0 -O0、PentiumD 3.2GHz OpenBSD44R。
0.46msec	sj3-2.0.1.23（ネットワークソケット接続モード）（sj3標準辞書）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。-g0 -O0、PentiumD 3.2GHz OpenBSD44R。
0.41msec	sj3-2.0.1.23（ファイルソケット接続モード）（sj3標準辞書）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。-g0 -O0、PentiumD 3.2GHz OpenBSD44R。
0.36msec	sj3-2.0.1.23（ネットワークソケット接続モード）（追加辞書でanthyの通常辞書の４割くらいの量）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。-g0 -O2、PentiumD 3.2GHz OpenBSD44R。
0.32msec	sj3-2.0.1.23（ネットワークソケット接続モード）（sj3標準辞書）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。-g0 -O2、PentiumD 3.2GHz OpenBSD44R。
0.30msec	sj3-2.0.1.23（ファイルソケット接続モード）（追加辞書でanthyの通常辞書の４割くらいの量）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。-g0 -O2、PentiumD 3.2GHz OpenBSD44R。
0.27msec	sj3-2.0.1.23（ファイルソケット接続モード）（sj3標準辞書）で、１文の内容を変換するのに要する時間。変換内容を読点で無理矢理分割した場合。-g0 -O2、PentiumD 3.2GHz OpenBSD44R。
0.116msec	チーラの一分

ネットブックだと、この 2.5〜３倍くらいかかると思う。 Anthy だとたぶん 160〜300ms くらい。
Android携帯や iPhone携帯だと、この 12〜16倍以上はかかるのではないかと思われる。 Anthy だともしかしたら 750ms〜約２秒。

拙作パッチで５割増〜２倍も遅くなっているのは、 変換内容への学習の適用と、変換結果からの学習の抽出にて、 大幅に変更（もしかしたら木構造データベース処理部以外は全部書き変えたかも）し、 大量の文字列の取り出し／連結／分割を行う様になったのが効いているのではないかと思われる。
＃ anthy の設計仕様では、文字列の取出／連結／分割の操作１回に付き malloc() が２回と free() が２回付いてくるが、これの負荷が高い。

Thu,09 Jul,2009 追記：
Canna35b2 の変換所要時間を計測。なんとなく体感してはいたが、やっぱり速い。但し変換結果はまるで出鱈目だった。
「|タトエバコンナカンジノブンショウガ１０ブンセツトナルナイヨウ|を|変換すると|結果|波動|奈留のだろう。|」
読点を突っ込んでようやくそれっぽくなったが。
「|例えば、|こんな|漢字の、|文章が、|１０|文節となる、|内容を、|変換すると、|結果は、|どう|奈留のだろう。|」

Wed,09 Sep,2009 追記：
拙作パッチ版の測定対象を anthy-9100h.patch13Bptn23.iconv.alt-depgraph-090712 に改訂。
「|例えば|こんな感じの|文章が|10文節と|なる|内容を|変換すると|結果は|どうなるのだろう|。|」
「|例えば|、|こんな感じの|、| 文章が|、|10文節と|なる|、|内容を|、|変換すると|、|結果は|、|どうなるのだろう|。|」

Thu,10 Sep,2009 追記：
sj3 の計測結果を追加。
追加辞書に使用した物は、 こちら 「ArtRecords - unixの日本語環境構築日記:) 賢いかな漢字変換システム Sj3」 の visual+.dic.gz。   追加辞書にて Canna や Anthy なみの大きな辞書を使用せず、 Canna や Anthy の半分以下の大きさの辞書でしか試していないのは、 sj3 は辞書の登録可能単語数の上限が小さいらしいので。
変換結果は、
「たとえばこんな漢字の文章が１０分説となる内容を変換すると結果はどうなるのだろう．」
「たとえば，こんな漢字の，文章が，１０分説となる，内容を，変換すると，結果は，どうなるのだろう．」
どこで文節を区切ったかの見方が判らん。

Thu,10 Sep,2009 追記：
FreeWnn の計測結果を追加。
変換結果は、
「|例えば|こんな|漢字の|文章が|10|文節となる|内容を|変換すると|結果|波動|なるのだろう。|」

Thu,10 Jul,2009 追記：
canfep の出力から tty 制御用のエスケープシーケンスの山を削除したら ３倍速くなったので、Canna35b2 の変換所要時間を測定し直し。

結論：
体感していた通り、Anthy の変換は遅い。
ただ、Canna や FreeWnn は速いと言っても、 連文節の区切りを覚えてくれないから……。
sj3 は何故こんなにも速いのか不思議なのと、 辞書の登録可能単語数の上限が小さいのがどう効いてくるか……。 それから、連文節の区切りの学習は有るらしい。

Sat,21 Nov,2009：

Anthy 累計学習量の変化(18KiB)

Thu,08 Sep,2011：

Anthy 累計学習量の変化(18KiB)

これまでの結果のまとめ：

Anthy の実装アルゴリズム上の限界点：

いきなりですが、具体例：

コーパスの例文に
|いったら|いい| |行ったら|いい|
|きにいる|はずよ| |気に入る|筈よ|
|こっちゃ|ない| |こっちゃ|ない|
の３つを追加し、 かつ「|こっちゃ|ない|」が 『「#T35 こっちゃ」|「#KY な」「付属語：い」』として認識された場合、 「へんかんがようい」の変換結果が 「|変|閑雅よ|うい|」（|へん|かんがよ|うい|）になります。 例文に
|へんかんが|ようい| |変換が|容易|
を追加しても、 「へんかんがようい」の変換結果は 「|変|閑雅よ|うい|」（|へん|かんがよ|うい|）のまま変わりません。
なお、anthy のバージョンや辞書の構成や作業環境などにより、 「|こっちゃ|ない|」が 『「#R5 こ」「付属語：っちゃ」|「#T35 ない」』等と認識される事があり、 この場合は上記の現象は発現しません。

解析結果：

「|行ったら|いい|」から『|A Se 付属語「い」|』が、 「|気に入る|筈よ|」から『|Ve Se|Ne Se 付属語「よ」|』が、 抽出され、コーパスのデータベースに登録される。
「|こっちゃ|ない|」に関しては、 『|Ne Se|Ne Se 付属語なし|』と認識する場合と、 『|Ne Se|A Se 付属語「い」|』と認識する場合と、別れるが、 make update_params にて 「|行ったら|いい|」から『|A Se 付属語「い」|』を登録した後に make update_params2 を行うと、 『|Ne Se|A Se 付属語「い」|』と認識する場合が少なくないと思われる （必ずそうなる訳ではない）。
こうして、 『|Ve Se|Ne Se 付属語「よ」|』、 『|Ne Se|A Se 付属語「い」|』、 が、コーパス由来の確率データベースに登録された状態で、 「へんかんがようい」を変換すると。
「|経ん|閑雅よ|うい|」（|へん|かんがよ|うい|）という文節区切り候補に関して、 コーパスから覚えた 『|Ve Se|Ne Se 付属語「よ」|』が「|経ん|閑雅よ|」（|へん|かんがよ|）の部分に、 『|Ne Se|A Se 付属語「い」|』が「|閑雅よ|うい|」（|かんがよ|うい|）の部分に、 それぞれ一致するので、文節区切り位置として優先されるらしい。
文節区切り位置が決まった後に、 各文節に対して変換候補一覧の生成と並び順の決定が行われるが、 その時、第１文節の「|へん|」に関しては、 「|経ん|」よりも「|変|」の方が評価が高いらしく、 提示される変換候補が 「|変|閑雅よ|うい|」（|へん|かんがよ|うい|） に変わったりする。

対処法：

例文に
|へんかんが|ようい| |変換が|容易|
を追加しても駄目でした。例文に
|へん|かんがよ|うい| |~変|~閑雅よ|~うい|
を追加し、 『|Ve Se|Ne Se 付属語「よ」|』、 『|Ne Se|A Se 付属語「い」|』、 を強制的にコーパス由来の確率データベースから削除したところ、 ようやく「|変換が|容易|」（|へんかんが|ようい)）が 第１候補として提示される様になりました。
がしかし、 『|Ve Se|Ne Se 付属語「よ」|』、 『|Ne Se|A Se 付属語「い」|』、 をデータベースから削除しているので、 「|（動詞）（付属語有無問わず）|（名詞）よ|」や 「|（名詞）（付属語有無問わず）|（形容詞）い|」といった 構文の事を忘れている筈です。

と言う訳で：

Anthy-8600 以降（これを書いている時点では 9100h まで同様）で 実装されている文節区切りアルゴリズムである 「品詞＆付属語ベース 文節２グラム MBR ビタビ アルゴリズム」の、 Anthy（具体的にどのバージョンの範囲まで該当するかは未確認）で 行われている実装方法だと、 「なにがしかの構文を覚えると、別の構文が覚えられなくなる」 と言うパターンが存在します。

それは特殊な例外です、理論に問題はありません、？：

明確にコケる組み合わせを具体的な組み合わせとして見つけたのは、 上記の例で３パターン目ですが、 前２パターンは運悪く特殊な例外を引いてしまったと思って 記録も取らずに忘れ去っていました。
いちいちこんなコケるパターンを探しても何の得にもならないので わざわざ探しはしませんが。 運悪く滅多に発生しない様な特殊なパターンを引き当ててしまったのか。 それとも 滅多に具体的な追究をしないから表面化しないだけで 潜在的にこの手のパターンが山ほど存在しているのか。

注意：

上記の内容は、 Anthy のコーパス例文や辞書メンテナンスをされる方が ドツボにはまって泥沼に落ち込まない様に注意喚起の為 （この手のパターンに遭遇した場合、 理論上？設計上？の限界を越えてしまっているので、 現場でどう頑張っても無駄です）、 あるいは新規にかな漢字変換エンジンの開発をされる方の参考情報として、 提起するものであり、 Anthy が良いとか悪いとか言う話ではありません。

その他、作業していて気付いたことなど：

これらの変更を行った事で、 一字一句誤りの無い学習データを貯めさえすれば、 文語でちょっと硬めの文書の入力には、 それなりに使えるかな漢字変換になったと思いますが。   今度の問題は 「一字一句誤りの無い学習データ」を「貯める」 事ですかね。

漢字コード入力、漢字コード表入力、 単漢字変換／部首変換／画数変換、 単語変換、単文節変換、連文節変換。 思えば遠くに来たもんだ。

Last modified on Sat,08 Oct,2011.
This contents was founded in Sun,02 Sep,2007.
↑ FENIX ほめぱげ
← G-HAL ほめぱげ
→ ソフトヱアに関するウダウダ
→→ 未整理なジャンクのうだうだ
→→→ 未整理なソフト - 日本語入力関連
↓ Mail to, メールはこちらへ
↓ Suggestion Box, 投書箱
↓ BBS, 掲示板 UserName:BBS、Password:BBS
(C) 2007 G-HAL